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FOREWORD 


The  purpose  of  this  paper  is  to  make  available  substantive  work  done  in  response  to  a 
major  cooperative  technical  support  activity  among  agencies  in  the  US  and  many  NATO  nations. 
Specifically,  this  paper  was  prepared1  by  the  Institute  for  Defense  Analyses  (IDA)  in  support  of  the 
Supreme  Headquarters  Allied  Powers  Europe  (SHAPE)-sponsored  Army  Tactical  Command  and 
Control  Information  System  (ATCCIS)  Phase  m  study  effort  and  the  Defense  Information 
Systems  Agency  (DISA),  Joint  Interoperability  and  Engineering  Organization  (JIEO),  Center  for 
Standards.  The  contents  of  this  document  were  reviewed  and  agreed  to  in  the  international 
ATCCIS  forum,  and  issued  by  SHAPE  as  a  NATO  UNCLASSIFIED  document  with  the  same 
title.  It  was  also  reviewed  by  the  Center  for  Standards,  Directorate  for  DoD  Standards  Assistance. 
Comments  from  NATO  and  national  commands  and  agencies  were  solicited  and  have  been 
incorporated.  SHAPE  will  be  distributing  this  paper  to  all  NATO  nations  and  to  those  NATO 
commands  and  agencies  that  have  expressed  an  interest  in  the  ATCCIS  study.  Additional 
distributions  are  planned  by  the  ATCCIS  nations,  NATO  Headquarters  (to  the  TSGCE),  and 
NACISC  (to  the  Information  Systems  Working  Group).  Background  information  relating  to  the 
overall  ATCCIS  effort  is  contained  in  the  Preface  to  this  paper. 

This  document  is  a  joint  effort  between  JIEO,  OSD,  and  the  US  Army.  It  is  a  major 
revision  of  Technical  Standards  for  Command  and  Control  Information  Systems,  ATCCIS 
Working  Paper  25  (WP  25),  Edition  3,  January  1992,  and  of  the  update  to  the  above  document, 
IDA  Paper  P-2805  (Volumes  I  and  II),  December  1992,  prepared  for  JIEO.  The  focus  remains 
the  identification  of  open  standards  that  could  be  used  to  achieve  interoperability  of  command  and 
control  information  systems  (CCISs),  but  the  document  is  applicable  to  a  wide  range  of 
information  systems  and  information  technology  activities.  This  document  has  had  significant 
contributions  from  NATO  organizations  and  national  staffs;  SHAPE;  and,  in  the  United  States,  the 
Services,  JIEO,  and  other  organizations. 

This  document  has  been  reorganized  and  extended  to  be  aligned  with  the  Technical 
Reference  Model  contained  in  Edition  2.0  of  the  US  DoD  Technical  Architecture  Framework  for 
Information  Management.  The  document  places  increased  emphasis  on  the  use  of  profiles  to 
achieve  interoperability. 

The  Office  of  the  Director  of  Information  Systems  for  Command,  Control, 
Communications  and  Computers  (ODISC4),  Headquarters  Department  of  the  Army,  provides  the 
US  delegate  to  the  ATCCIS  Permanent  Working  Group  (PWG),  representing  SHAPE,  Allied 
Forces  Central  Europe  (AFCENT),  SHAPE  Technical  Centre,  Denmark,  France,  Germany,  the 
Netherlands,  Spain,  the  United  Kingdom,  and  the  United  States.  Within  the  United  States, 
operational  issues  are  coordinated  with  the  US  Army  Training  and  Doctrine  Command.  Technical 
issues  are  coordinated  with  the  US  Army  Space  and  Strategic  Defense  Command  and  the  US  Army 
Communications-Electronics  Command.  IDA  provides  technical  and  analytical  expertise  in 
support  of  the  US  contributions  to  the  overall  ATCCIS  effort.  ODISC4  also  furnishes  the  U.S. 


1  This  document  was  prepared  in  response  to  requests  from  the  Office  of  the  Assistant  Secretary  of  Defense  (C3I), 
Theater  and  Tactical  Command,  Control,  and  Communications  under  Contract  MDA903-89-C-0003.  Task  Order 
T-J 1-246,  and  the  Joint  Interoperability  and  Engineering  Organization  (JIEO),  Defense  Information  Systems 
Agency  (DISA),  Task  Order  T-S5-1211.  Funding  for  Task  T-Jl-246  was  provided  by  the  US  Army  Office  of 
the  Director  of  Information  Systems  for  Command,  Control,  Computers,  and  Communications  (DISC4). 
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delegate  to  the  ATCCIS  Steering  Group,  which  provides  overall  direction  and  approval  of  the 
ATCCIS  PWG  work  effort.  This  document  should  be  of  primary  interest  to  the  combat 
development  and  system  development  communities  of  those  US  Commands  and  Agencies  whose 
focus  is  on  longer  term  command  and  control  requirements  (i.e.,  the  year  2000  and  beyond). 

The  authors  would  like  to  acknowledge  the  following  persons  for  contributions  and 
comments  on  standards  and  examples  of  military  initiatives  to  use  open  standards:  Mr.  Nelson 
Alvarez  (DISA/JIEO),  LTC  Dan  Almero  (US  Army,  Vice-Chair,  WG3  on  Land  Operations, 
ADSIA),  LCDR  Katie  Bryant  (DISA/JIEO),  LCDR  David  Chappell  (DISA/JIEO),  Mr.  Walt 
Claasen  (LOGICON),  Dr.  Frank  Curcio  (DISA/JIEO),  Mr.  Silvano  Goldoni  (NACISA), 
CDR  Tony  Hunt  (UK  Royal  Navy,  SHAPE),  Mr.  Wouter  Konings  (ISWG/NACISC),  Mr.  David 
Lambert  (BICES  Team),  MAJ  Michael  Mascarenas  (USMC),  Mr.  Richard  McLane  (DISA/JIEO), 
Mr.  Salvatore  Manno  (DISA/JIEO),  Mr.  Joseph  Onufer  (US  Army  CECOM),  Mr.  Henry  Saphow 
(OPM  FATDS,  US  Army),  Mr.  Stan  Levine  (OPM  CHS,  US  Army),  Dr.  A.  Rannestad  (NATO 
Intranational  Staff),  Ms.  Judy  Simpson  (LOGICON/Eagle  Technologies),  Mr.  Hal  Staton  (NSA), 
and  Ms.  Christina  Vicini  (NACMA).  The  substantial  technical  support  of  the  sponsors,  Mr.  Vic 
Russell  [OASD(C3I)-T&TC3]  and  LCDR  Doug  Schroeder  (DISA/JIEO),  as  well  as  the 
US  Representative  to  ATCCIS,  LTC  Steve  Woffinden  (US  Army  ODISC4),  is  gratefully 
acknowledged. 
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PREFACE  FOR  ATCCIS 

1.  In  1978,  NATO's  Long  Term  Defence  Plan  (LTDP)  Task  Force  on  Command  and 
Control  (C2)  recommended  that  an  analysis  be  undertaken  to  determine  if  the  future  tactical 
Automatic  Data  Processing  (ADP)  requirements  of  the  Nations,  including  interoperability,  could  be 
obtained  at  a  significantly  reduced  cost  when  compared  with  the  approach  that  had  been  adopted  in 
the  past  The  Task  Force  also  recommended  that  the  analysis  should  determine  whether  tactical 
ADP  systems  could  be  developed  according  to  technical  standards  prescribed  by  NATO  and  agreed 
upon  by  the  Nations. 

2.  In  early  1980  the  then  Deputy  Supreme  Allied  Commander  Europe  initiated  a  study  to 
investigate  the  possibilities  of  implementing  the  Task  Force's  recommendations.  Three  Nations, 
those  with  experience  in  fielding  automated  tactical  command  and  control  information  systems, 
participated  in  Phase  I  of  the  study,  with  Supreme  Headquarters  Allied  Powers  Europe  (SHAPE) 
as  leader  and  coordinator.  The  study  group  reported,  at  the  end  of  Phase  I,  that  the  Nations  could 
increase  interoperability  and  potentially  reduce  costs  by  using  a  common  development  approach. 

3.  The  Army  Tactical  Command  and  Control  Information  System  (ATCCIS)  Phase  II 
study,  under  the  direction  of  a  steering  group  chaired  by  SHAPE  and  consisting  of  representatives 
from  the  Central  Region  (CR)  Nations  and  Allied  Forces  Central  Europe  (AFCENT),  was 
established  in  1984.  Concurrently,  a  permanent  working  group  (PWG)  was  formed  which 
consisted  of  military,  technical,  and  analytical  representatives  from  France,  Germany,  the  United 
Kingdom,  the  United  States,  SHAPE  and  AFCENT,  and  technical  support  from  SHAPE  Technical 
Centre  (STC)  to  progress  die  Phase  II  effort  That  effort  commenced  in  January  1985  and  finished 
in  October  1990;  it  recommended  that  all  NATO  Nations,  as  well  as  the  Allied  Command  Europe 
(ACE)  Northern  and  Southern  Regions,  be  invited  to  participate  in  a  Phase  m  effort 

4.  ATCCIS  Phase  in  has  the  aim  of  demonstrating  the  ATCCIS  architecture  and 
operational  requirements  in  a  multi-national  scenario  with  each  participating  nation  fielding 
ATCCIS  conformant  systems.  The  demonstration  phase,  sponsored  by  SHAPE  commenced  in 
January  1992.  As  of  July  1993,  three  additional  nations  had  agreed  to  participate  in  ATCCIS  as 
full  participating  members,  i.e.,  the  Netherlands,  Denmark  and  Spain,  with  three  nations 
observing,  i.e.,  Belgium,  Canada  and  Italy.  The  work  of  the  PWG  supports  the  Military  Agency 
for  Standardization  (MAS)  Army  Board  (AB)  initiative  to  modernize  critical  C2-related  STANAGs; 
additionally,  it  will  harmonize  its  work  with  the  Allied  Data  Systems  Interoperability  Agency 
(ADSIA)  and  will  maintain  links  with  the  Allied  Tactical  Communications  Agency  (ATCA)  to 
ensure  that  no  duplication  of  effort  occurs.  The  PWG  also  coordinates  its  activities  with  the  Tri- 
Service  Group  on  Communications  and  Electronics  (TSGCE). 
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TECHNICAL  STANDARDS  FOR  COMMAND  AND  CONTROL 
INFORMATION  SYSTEMS  (CCISs)  AND  INFORMATION 

TECHNOLOGY 


1.  INTRODUCTION 

1 . 1  Derivation 

This  paper  originally  derived  from  the  Phase  n  Working  Paper  (WP)  24  [Ref. 
ATCCIS  1988],  which  defines  the  basic  concepts,  logical  elements  (called  facilities),  and 
attributes  of  the  architecture  for  the  Army  Tactical  Command  and  Control  Information  System 
(ATCCIS),  a  common  army  command  and  control  system  concept .  >r  the  year  2000  and  beyond. 
The  objectives  of  the  ATCCIS  architecture  are  to  achieve  interoperability  through  common 
standards  and  maintain  the  potential  to  reduce  costs  of  future  command,  control,  and  information 
systems  (CCISs),  without  unnecessarily  restricting  national  options  for  implementation.  The  paper 
has  been  recently  reorganized  and  extended  to  be  consistent  with  the  POSLX  Open  Systems 
Environment  (OSE)  Reference  Model  (P1003.0)  developed  by  the  Institute  of  Electrical  and 
Electronics  Engineers  (IEEE)  [Ref.  IEEE  1993]  and  is  now  applicable  and  useful  for  all  defense 
information  systems. 

1.2  Purpose 

The  purpose  of  this  paper  is  to  identify  the  technical  standards  that  are  applicable  to 
automated  information  systems  (AISs),  including  CCISs.  These  systems  are  defined  to  be  a 
combination  of  information,  computers,  and  telecommunications  resources  and  other  information 
technology,  together  with  personnel  resources,  that  collect,  record,  process,  store,  communicate, 
retrieve,  and  display  information  [Ref.  DoD  7920.2  1990] 

This  paper  identifies  standards  that  can  be  used  to  define  implementations  of  information 
systems.  In  this  paper,  existing  and  planned  standards  appropriate  to  the  1 1  service  areas  common 
to  most  AISs  are  surveyed  to  the  level  of  detail  necessary  to  confirm  a  reasonable  basis  for  the 
future  support  of  the  CCIS  requirements.  Relevant  standards  are  identified,  but  no 
recommendations  for  selecting  standards  are  considered.  Gaps  in  current  and  planned  standards 
coverage,  which  may  require  some  developmental  effort,  are  identified  and  are  being  passed  to  the 
appropriate  standards  defining  bodies,  including  those  within  NATO.  This  document  also  offers 
guidance  in  ensuring  adequate  coverage  by  the  set  of  standards  employed  at  the  time  of 
implementation. 

It  is  not  yet  known  to  what  degree  international  commercial  standards  can  be  made  to 
satisfy  CCIS  requirements,  but  it  is  assumed  that  the  extraordinary  investments  in  open  system 
standards  during  die  1980s  and  1990s  could  have  a  major  impact  on  the  next  generation  of  CCISs. 
As  the  nations  explore  the  use  of  these  standards  in  their  military  and  non-military  systems,  many 
of  the  practical  issues  not  addressed  in  this  paper  will  be  resolved. 
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1.3  Scope 

This  working  paper  presents  information  and  analyses  that  are  intended  to  support  defense 
AISs,  with  particular  emphasis  on  the  exchange  of  data  that  preserves  the  meaning  and 
relationships  of  the  data  exchanged  (termed  “basic  interoperability”). 

This  paper  contains  information  on  existing  and  planned  international,  voluntary, 
government,  and  de  facto  standards  that  promote  interoperability  and  portability,  ensure  flexibility 
and  growth  potential,  and  allow  for  technology  insertion  through  use  of  commercial  off-the-shelf 
(COTS)  products  and  nondevelopmental  items  (NDIs).  The  paper  identifies  relevant  standards  and 
gaps  in  current  and  planned  standards  coverage  that  may  require  development  effort  It  does  not 
however,  provide  a  detailed  evaluation  of  the  standards,  but  instead  focuses  on  standards  activities 
leading  to  future  standards  as  well  as  the  current  issues  surrounding  these  activities. 

This  paper  provides  a  broad  overview  of  the  existing  and  developing  technical  standards 
applicable  to  AISs,  to  include  automated  CCISs.  Very  little  of  the  work  is  specific  to  tactical 
CCISs.  The  standards  are  applicable  to  many  types  of  information  systems  and  have  been  the 
attention  of  many  national  and  international  efforts  to  reduce  acquisition  costs  of  government-  and 
industry-procured  systems. 

The  scope  of  the  analysis  of  standards,  which  is  the  focal  point  of  this  paper,  is  broad, 
extending  to  international  and  national,  commercial  and  military  standards.  However,  the 
emphasis  is  on  international  commercial  standards  with  military  enhancements  where  required. 

The  technical  scope  is  intended  to  match  that  of  the  application  platform  services  described 
in  the  current  version  of  the  Technical  Reference  Model  (TRM)  [Ref.  TAFIM  1993,  Volume  2], 
depicted  in  Figure  1,  which  is  a  modification  of  P1003.0,  the  POSIX  OSE  Reference  Model  and 
which,  in  turn,  is  the  basis  for  the  NATO  Open  Systems  Environment  (OSE)  Reference  Model 
[Ref.  NATO  OSE  1993].  Substantial  new  material  has  been  added  to  this  document  in  areas  such 
as  distributed  system  services,  object  management,  lower-layer  network  services,  security,  and 
system  management. 

1.4  Information  Sources 

This  assessment  is  based  primarily  on  a  review  of  standards  for  open  systems  developed 
by  the  International  Organization  for  Standardization  (ISO),  the  International  Electrotechnical 
Commission  (IEC),  and  the  International  Telecommunications  Union  (ITU)  •  Telecommunication 
Standardization  Sector  (ITU-TS)  [formerly  the  International  Telegraph  and  Telephone  Consultative 
Committee  (CCITT)].  Since  ISO/IEC  has  decided  to  use  the  profiles  of  standards  being  developed 
by  regional  standards  workshops,  the  primary  sources  for  profiles  are  those  workshops.  Use  of 
open  systems  standards  in  the  North  Atlantic  Treaty  Organization  (NATO)  is  the  responsibility  of 
the  Tri-Service  Group  on  Communications  and  Electronics  (TSGCE)  Subgroup  9  (SG9)  on  Data 
Distribution;  thus,  TSGCE  SG9  draft  Standardization  Agreements  (STANAGs),  the  draft  NATO 
Open  Systems  Interconnection  Profile  (NOSIP)  Strategy  [Ref.  NATO  1993a],  NATO  Technical 
Interoperability  Standards  (NTIS)  Transition  Strategy  [Ref.  NATO  1991],  and  working  documents 
from  international  and  national  sources  form  the  basis  of  the  assessment  of  military  use  of  open 
systems  standards. 
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Figure  1.  Example  Technical  Reference  Model 


Access  to  many  of  the  key  documents  has  been  the  result  of  the  contributions  of  experts 
from  many  nations  and  from  maintaining  active  membership  in  the  Open  Software  Foundation 
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(OSF),  the  Object  Management  Group  (OMG),  and  the  American  National  Standards  Institute 
(ANSI)  Accredited  Standards  Committee  (A SC)  X3T5.1 

Hie  cut-off  date  for  information  contained  in  this  paper  is  February  1994.  Hie  primary 
effect  of  the  cut-off  date  is  that  the  progression  of  some  standards  to  committee  draft  (CD),  draft 
international  standard  (DIS),  and  international  standard  (IS  or  ISO)  status  may  not  be  fully 
reflected  herein.2 

1.5  Methodology  for  ATCCIS  Standards  Analysis 

This  section  describes  the  methodology  employed  to  identify  the  group  of  existing  and 
planned  standards  required  to  support  required  system  functionality  (for  AlSs,  CCISs,  or 
specifically  ATCCIS)  and  to  assess  the  completeness  of  standards  coverage.  The  methodology  is 
illustrated  in  Figure  2. 

The  ATCCIS  architecture  will  be  defined  by  adopting  existing  or  emerging  standards 
wherever  and  whenever  possible.  Further,  when  such  a  standard  cannot  be  found  ATCCIS  will 
identify  the  requirement  for  a  standard  to  be  developed  and  will  pass  such  a  requirement  to  the 
appropriate  standards  defining  body  within  NATO.  Each  facility  in  the  ATCCIS  architecture  is  a 
logical  entity  that  provides  a  set  of  related  services;  implementation  of  a  facility  is  not  defined  by 
the  architecture  and  is  a  national  responsibility  for  each  system.  This  paper  identifies  standards 
(and  options  within  standards)  that  are  applicable  to  each  facility,  but  the  paper  does  not 
recommend  specific  standards  or  groups  of  standards.  Selection  of  appropriate  standards,  as  well 
as  the  basic  design  choices  implicit  in  the  standards  and  options  within  standards,  will  be  made  by 
agreement  prior  to  implementation  decisions. 

Following  a  review  of  the  required  services,  the  next  step  is  to  identify  the  base  standards 
appropriate  for  each  group  of  services.  These  standards  may  come  from  international,  NATO, 
national  military,  or  national  non-military  standards  bodies,  and  they  may  be  existing  or  planned. 
High-level  options  within  standards  applicable  to  CCISs  are  identified.  (Sources  and  the 
development  process  for  international  standards  are  discussed  in  Chapter  3.) 

For  many  functions,  there  are  several  interrelated  standards  that  must  be  used  together  to 
provide  the  required  services.  In  most  cases  there  is  an  order  or  hierarchy  among  these  standards 
in  which  the  lower  levels  are  closer  to  physical  means,  and  higher  levels  are  associated  with 
applications  that  are  independent  of  the  physical  means.  An  ordered  grouping  of  standards  is 
called  a  stack.  A  profile  is  a  stack  of  standards  for  which  the  interoperability  parameters  are 
partially  or  fully  specified  (profiles  usually  represent  agreements  among  implementors).  Where 
applicable  to  services  required  by  CCISs,  stacks  will  be  constructed  and  illustrated  in  tables  or 
figures. 

Assurance  of  adequate  standards  coverage  is  addressed  in  three  ways.  First,  WP25 
checks  for  the  existence  of  standards  that  generally  support  each  specific  ATCCIS  function. 
Requirements  for  which  no  existing  or  planned  standard  seems  to  exist,  or  for  which  existing 


1  Accredited  Standards  Committees  such  as  X3TS  operate  under  the  procedures  of  ANSI  and  art  technically  not 
part  of  ANSI;  nevertheless,  in  this  document,  ANSI  ASC  X3T5  is  abbreviated  as  ANSI  X3T5. 

2  Significant  contributions  have  been  received  from  representatives  to  TSGCE,  the  UK  Defence  Research  Agency 
(DRA),  the  American  National  Standards  Institute  (ANSI),  the  US  National  Institute  of  Standards  and 
Technology  (NIST),  the  US  Defense  Information  Systems  Agency  (Joint  Interoperability  and  Engineering 
Organization),  the  Open  Software  Foundation  (OSF),  Omnicom,  and  Technology  Appraisals  (UK). 
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standards  do  not  seem  to  be  adequate,  are  identified  so  that  these  needs  may  be  referred  to  the 
appropriate  NATO  standards  defining  body. 
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Figure  2.  Ovsrvfsw  of  ths  Methodology  for  ATCCIS  Standards  Analysis 

On  a  more  specific  level,  a  methodology  for  ensuring  adequate  standards  coverage  through 
detailed  analysis  has  been  developed.  An  interoperability  parameter  approach  is  defined  that  begins 
with  the  identification  of  the  system  design  parameters  whose  control  is  required  to  achieve 
interoperability.  The  assembled  parameters  act  as  a  checklist  for  interoperability  since  each 
interoperability  parameter  must  be  controlled  by  a  suitable  standard.  The  purpose  of  an  analysis 
using  interoperability  parameters  is  to  recognize  and  examine  all  relevant  quantities  and 
characteristics  in  a  direct  manner,  instead  of  assuming  that  existing  or  draft  standards  will  provide 
adequate  coverage  of  the  quantities.  Appendix  B  discusses  this  approach  in  more  detail  NATO's 
TSGCE  SG9  and  ISO/IEC  have  developed  a  format,  called  a  standardized  profile,  for  specifying 
stacks  and  interoperability  parameters.  Standardized  profiles  are  discussed  in  Chapter  16,  and 
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examples  are  provided  in  Appendix  L  The  status  of  NATO  work  to  address  military  deficiencies  in 
open  system  standards  (primarily  for  network  services)  is  given  in  Chapter  17. 

In  the  third  step  of  the  coverage  analysis,  the  array  of  standards  identified  that  could 
support  ATCCIS  is  compared  with  plans  for  near-term  efforts  to  check  for  completeness.  Near- 
term  efforts  include:  developing  NATO  C2  systems,  such  as  the  Air  Command  and  Control 
System  (ACCS);  and  conducting  multilateral  interoperability  demonstrations,  such  as  the 
Quadrilateral  Interoperability  Programme — these  are  discussed  in  Chapter  18.  National  initiatives 
for  military  use  of  OSI  standards  are  reviewed  in  Chapter  19,  and  detailed  examples  are  given  in 
Appendix  C.  In  addition  to  providing  a  check  on  completeness  of  ATCCIS  applicable  standards, 
some  of  these  near-term  efforts  are  of  interest  because  they  represent  transition  strategies  for 
moving  to  open  environments  for  information  processing  and  exchange. 

1.6  Structure  of  the  Paper 

Figure  3  identifies  the  roles  of  each  of  the  chapters.  Chapter  2  provides  an  overview  of  the 
standardization  process  and  is  essential  to  understanding  the  assessment.  Chapter  3  provides 
background  on  architectures,  frameworks,  and  reference  models.  The  remaining  chapters  are 
generally  independent  and  can  be  read  in  any  order.  Chapters  4  to  14  address  the  1 1  service  areas 
shown  in  Figure  1  (above):  software  engineering,  user  interface,  data  management,  data 
interchange,  graphics,  network,  operating  system,  security,  system  management,  distributed 
computing,  and  internationalization.  Chapter  IS  describes  the  interface  standards  essential  to 
ensuring  that  applications  entities  are,  to  die  extent  possible,  independent  of  hardware.  Chapter  16 
summarizes  international  and  national  activities  to  develop  profiles  of  standards  in  order  to  ensure 
common  sets  of  interoperability  parameters  are  selected  for  acquisition.  The  work  in  NATO  and 
national  military  organizations  to  adopt,  modify,  and  implement  open  systems  standards  is 
reviewed  in  Chapters  17-19.  Chapter  20  summarizes  the  issues  uncovered  in  the  previous 
chapters. 

Several  appendixes,  some  lengthy,  are  provided  as  reference  material.  Appendix  B 
expands  the  discussion  of  the  interoperability  parameter  methodology  and  applies  the  approach  to 
some  commonly  used  standards  (RS-232,  RS-423,  STANAG  4202,  and  ITU-TS  X.25). 
Appendix  C  provides  examples  of  profiles  of  national  initiatives  to  address  the  military  use  of  OSI 
standards.  A  compilation  of  technical  standards  being  developed  by  ISO  and  ITU-TS  is  given  in 
Appendixes  D  and  E,  the  former  listed  by  layer  of  the  OSI  Reference  Model  and  the  latter  listed 
numerically.  Appendix  F  identifies  the  role  and  (in  some  cases)  the  standards  responsibility  of 
international  and  national,  both  civil  and  military,  standards  bodies.  Appendix  G  provides  some 
detailed  information  on  the  work  plans  for  one  of  the  major  subcommittees  (SC21)  ISO/IEC 
(JTC1).  Appendix  H  identifies  STANAGs  and  other  military  and  commercial  standards  being 
developed  for  use  in  open  systems.  Appendix  I  summarizes  the  application,  transport,  and  relay 
functional  profiles  identified  for  use  in  NATO.  Appendix  J  identifies  the  status  of  and  the  military 
features  contained  in  the  open  systems  interconnection  (OSI)  STANAGs  being  developed  by  the 
TSGCE.  An  index  is  provided  to  assist  the  reader  in  locating  information  on  specific  topics  and 
standards. 
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2.  STANDARDIZATION  PROCESS 

2.1  Goals  for  Information  System  Standards 

The  desire  to  adopt  standards  that  govern  various  aspects  of  information  system  definition 
deriver-  from  the  following  goals: 

•  To  save  money  by  separating  software  from  hardware.  The  rapid  rate  of  change  in 
computer  hardware  technology  and  declining  prices  makes  it  desirable  to  be  able  to 
replace  hardware  and  hardware  vendors  without  having  to  rebuild  software. 
Standards  that  govern  the  interfaces  between  application  software  and  system  software 
limit  the  scope  of  such  changes  to  those  portions  of  the  system  software  that  manage 
die  hardware. 

•  To  save  money  by  promoting  competition  among  component  vendors.  The  existence 
of  open,  non-proprietary  standard  specifications  for  a  component  of  an  automated 
information  system,  either  hardware  or  software,  creates  a  market  in  which  multiple 
vendors  can  compete.  When  the  specifications  are  owned  by  one  vendor,  they  can 
lock  out  competition  for  after-market  components,  locking  in  the  user  to  the  software 
offered  by  the  hardware  vendor. 

•  To  facilitate  the  adoption  of  new  technology.  The  same  arguments  that  apply  to  saving 
money  also  apply  to  adopting  new  hardware  and  software  technology.  In  this  case, 
however,  part  of  the  advantage  of  having  standards  stems  from  the  architectural 
structure  imposed  by  the  process  of  grouping  the  standards  into  service  areas.  This 
isolates  die  impact  of  new  technology  to  only  that  portion  of  a  system  directly  affected 
by  the  change.  For  example,  the  adoption  of  voice  recognition  systems  would  only 
impact  die  user  interface  component  of  the  platform,  and  could  be  isolated  from 
existing  applications  while  permitting  new  applications  to  take  better  advantage  of  die 
new  capabilities. 

•  To  promote  operational  effectiveness  through  interoperability  between  systems 
belonging  to  different  organizations,  or  even  between  systems  of  the  same 
organization.  Interoperable  systems  are  ones  that  can  exchange  data  in  ways  that 
presave  the  meaning  of  the  data.  This  permits  users  with  the  appropriate  permissions 
to  access  data  not  previously  available  to  them  or  in  a  more  convenient  way.  This,  in 
turn,  allows  them  to  work  more  effectively,  more  efficiently,  or  both. 

•  To  promote  workplace  efficiency  through  the  integration  of  information  systems. 
Integration  goes  beyond  interoperability  to  make  applications  aware  of  other 
applications,  not  just  data.  Integrated  applications  offer  the  potential  for  better 
integrated  organizations,  and  the  potential  for  substantial  cost  savings  in  software 
development  by  sharing  applications  instead  of  rewriting  them. 

These  goals,  and  the  strategies  they  engender,  strongly  influence  the  standardization 
process  within  defense  organizations,  as  well  as  in  the  world  at  large.  For  example,  the  intention 
of  taking  advantage  of  marketplace  competition  has  spurred  some  nations  into  placing  commercial 
standards  ahead  in  priority  of  defense-unique  standards.  Similarly,  the  desire  to  more  quickly 
incorporate  new  technology  into  standards  faster  is  changing  the  procedures  in  use  for  the 
development  and  approval  of  proposed  standards  documents. 

2.2  Categorization  of  Standards 

Standards  can  be  categorized  in  several  ways.  One  is  by  content:  interface,  process,  or 
product  standards.  Interface  standards  are  the  least  restrictive  and  merely  define  certain 
characteristics.  Process  standards,  while  somewhat  more  restrictive,  define  die  manner  in  which  a 
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process  is  performed,  but  do  not  determine  die  actual  output  Product  standards,  since  they  define 
a  particular  output  or  outcome,  tend  to  be  the  most  restrictive.  These  categories  also  indicate  the 
likely  effects  of  a  particular  standard  (or  function  of  a  standard)  in  terms  of  whether  certain  groups 
may  resist  die  standard  and  how  well  die  standard  will  be  integrated  into  the  technology  life  cycle. 
For  example,  a  product  standard  promulgated  too  early  in  the  technology  life  cycle  may  be  resisted 
and  not  implemented  by  industry  because  it  does  not  allow  enough  flexibility  in  adapting  to 
anticipated  changes  in  the  technology.  Conversely,  simple  interface  standards  may  be  insufficient 
for  users  or  maintained  of  a  product  who  require  accurate  or  detailed  information  about  a  particular 
product  and  how  it  functions.  [Ref.  Putnam  1982]  Most  of  the  standards  described  in  this 
document  are  interface  standards. 

Two  additional  types  of  standards — reference  models  and  profiles — represent  an 
orthogonal  categorization  to  interface,  process,  and  produce  standards.  Reference  models  provide 
a  common  framework  for  a  group  of  standards  within  a  specific  area.  For  example,  the  model 
shown  in  Figure  1  (above)  establishes  a  very  high  level  structure  of  all  the  standards  of  interest  in 
the  area  of  application  platforms  for  AISs  by  dividing  the  platform  into  1 1  substructures,  many  of 
which  have  their  own  reference  models  to  provide  further  structure  to  their  area. 

Interface,  process,  and  product  standards  frequently  have  many  options.  Profiles  are 
defined  to  establish  a  commo  et  of  prions  so  that  the  goals  of  interoperability  and  integration  can 
be  realized  by  implementatii  of  the  standard.  Profiles  have  been  developed  from  at  least  two 
different  perspectives.  One,  represented  by  a  national  or  NATO  open  system  interconnection 
profile,  provides  both  a  selection  of  specific  standards  where  there  are  alternatives,  as  well  as  some 
of  the  specific  options  within  those  standards.  Others  represent  the  very  detailed  specifications  to 
be  used  by  a  specific  community  of  users  or  for  a  specific  purpose. 

Another  way  to  categorize  standards  is  by  issuing  body.  International  standards  are  issued 
by  an  organization  whose  standards  development  process  is  accepted  by  the  international 
community  as  being  an  open,  consensus-based  process.  National  standards  are  issued  by  similar 
organizations  at  the  national  level,  usually  with  governmental  backing.  Industry  standards  are 
issued  by  an  organization  that  provides  an  open  process  within  a  specific  industrial  area.  Those 
may  be  professional  societies,  such  as  IEEE,  or  trade  associations,  such  as  the  European  Computer 
Manufacturers'  Association  (ECMA).  Consortia  standards  are  issued  by  representatives  of  groups 
of  producers,  consumers,  and  government  bodies.  In  some  cases,  the  standards  development 
process  may  be  open  only  to  the  members  of  the  consortium.  These  different  kinds  of  issuing 
bodies  are  layered  to  some  degree.  The  members  of  the  international  organizations  are  die  national 
standards  bodies.  Industry  bodies  and  consortia  frequently  propose  their  standards  for  adoption 
by  the  national  bodies,  or  sometimes  directly  to  the  international  bodies.  Thus,  for  example,  an 
IEEE  standard  may  be  offered  to  ANSI  as  a  US  standard  and,  once  accepted,  offered  to  the 
International  Organization  for  Standardization  (ISO)  as  an  international  standard. 

Two  major  characteristics  distinguish  the  standards  produced  by  these  different  issuing 
bodies:  time  for  development  and  vendor  acceptance.  In  general,  the  narrower  the  scope  of 
consensus,  the  less  time  it  takes  to  develop  a  standard.  Consortia  standards  usually  take  the  least 
amount  of  time,  but  if  there  are  competing  consortia  within  a  single  area,  or  if  the  membership  is 
too  limited,  the  result  may  not  achieve  the  degree  of  vendor  acceptance  to  make  the  standards  de 
facto  standards.  On  the  other  hand,  international  standards  may  take  so  long  to  develop  that 
proprietary  products  become  de  facto  standards  and  are  very  hard  to  dislodge  in  the  marketplace. 
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An  rumple  of  the  latter  is  the  suspension  of  development  of  ISO’s  Terminal  Management  (TM) 
standard  in  favor  of  standardizing  the  popular  (de  facto)  X-Windows  user  interface. 

2.3  Standards  Organizations 

This  section  describes  selected  standards  organizations  and  the  process  used  by  each.  The 
organizations  described  are: 

•  International  Organization  for  Standardization  (ISO)  and  International  Electrotechnical 
Commission  (DEC) 

•  International  Telecommunications  Union  (ITU)  Telecommunications  Standardization 
Sector  (TTU-TS) 

•  American  National  Standards  Institute 

•  X/Open 

•  Tri-Service  Group  on  Communications  and  Electronics  (TSGCE) 

•  Regional  organizations  producing  standardized  profiles  for  adoption  by  ISO 

•  National  defense  organizations  developing  OSI  profiles,  such  as  the  US  Data 
Communications  Protocol  Standards  (DC PS)  Technical  Management  Panel  (DTMP). 

ISO.  Development  of  an  ISO  standard,  from  first  proposal  to  actual  publication  of  the 
standard,  is  an  arduous  and  time-consuming  process  that  ensures  the  final  result  to  be  acceptable  to 
as  many  countries  as  possible.  Figure  4  is  a  flowchart  of  the  process. 

The  process  begins  when  a  member  body,  often  referred  to  as  a  national  body  (NB), 
submits  a  new  work  item  (NWI)  proposal  (NP).  The  introductory  proposal  is  assigned  to  a 
working  group  (WG)  of  a  technical  committee  (TC)  or  subcommittee  (SC),  which  will  be 
responsible  for  progressing  the  document  through  the  standardization  process.  In  this  initial  stage, 
the  proposal  is  called  a  working  draft  (WD).  The  appropriate  WG  of  the  assigned  TC  publishes 
the  WD  in  the  form  of  a  committee  draft  (CD)  [prior  to  February  1990,  CD  was  known  as  a  draft 
proposal  (DP)].  The  CD  is  that  circulated  among  interested  members  for  a  3-month  balloting  and 
comment  period. 

If  the  CD  obtains  substantial  support,  it  is  then  circulated  (with  agreed  changes)  as  a  draft 
international  standard  (DIS)  for  a  6-month  balloting  period.  If  the  DIS  receives  a  majority  approval 
by  the  TC  members  and  75  percent  approval  from  all  voting  members,  it  is  advanced  to  the  Central 
Secretariat  If  the  balloting  of  die  DIS  is  negative,  the  DIS  text  is  revised  by  an  editing  committee 
and  resubmitted  as  a  second  DIS  for  balloting  or  demoted  to  CD  status  for  work  to  continue  on 
building  consensus.  The  Central  Secretariat  submits  an  approved  DIS  to  the  ISO  Council,  the 
board  of  directors  of  ISO.  The  council  accepts  the  DIS  as  an  international  standard  (IS),3  and 
finally,  ISO  publishes  the  international  standard. 

A  standard  that  has  achieved  DIS  status  is  considered  to  be  stable.  Only  minor  changes  are 
made  to  DIS  text  draft  prior  to  becoming  an  international  standard.  If  it  is  necessary  to  modify  an 
existing  or  emerging  standard,  there  is  an  addendum  process  whose  steps  are:  working  draft 
addendum  (WDAD),  proposed  draft  addendum  (PD AD),  draft  addendum  (DAD)  with  DIS  status, 
and  addendum  (AD)  with  international  standard  status.  A  similar  process  [working  draft 
amendment  (WDAM),  preliminary  draft  amendment  (PD AM),  draft  amendment  (DAM),  and 
amendment  (AM)]  is  used  for  amendments.  In  addition,  technical  corrigenda  may  be  approved  to 

3  ISO  i»  —cd  to  thij  docament  to  denote  m  imrmukul  standard  adopted  by  ISO  or  jointly  by  ISCVIEC. 
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correct  technical  mors  that  do  not  affect  the  intended  standardization.  A  technical  report  (TR)  is 
issued  first  as  a  working  draft  technical  report  (WDTR),  then  as  a  preliminary  draft  technical  report 
(PDTR),  and,  when  at  DIS  status,  as  a  draft  technical  report  (DTR). 

A  subcommittee  of  ISO/IEC’s  Joint  Technical  Committee  One  (JTC1)  on  Information 
Technology  may  suspend  the  five-stage  process  in  favor  of  the  fast  track  process,  initiated  by  a 
national  body  or  a  Category  A  liaison  organization,  provided  that  the  subcommittee  agrees: 

•  That  the  intended  fast  track  document  is  suitable  to  satisfy  the  requirements  of  the 
existing  JTC1  project 

•  To  use  the  fast  track  process  and  so  notifies  JTC1. 


Figure  4.  Flowchart  of  tha  ISO  Standardization  Process 


At  its  March  1993  Plenary  in  Beilin,  JTC1  requested  that  national  bodies  submit 
contributions  on  mechanisms  for  accelerating  the  3-stage  process,  and  additional  expediting 
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procedures  to  accommodate  other  situations  for  which  current  processes  may  not  be  timely.  At 
present,  fast  track  candidates  enter  the  ISO  process  as  CDs  for  DIS  balloting.  [Ref.  SC21  N  7713 
1993] 

The  ISO/IEC  JTC1  Special  Group  on  Functional  Standardization  (SGFS)  is  developing 
standards  for  international  standardized  profiles  (ISPs).  As  such,  they  bear  an  ISP  prefix  in  lieu  of 
the  traditional  ISO  prefix  although  their  numbers  follow  the  ISO  numerical  sequence.  Designations 
for  drafts  being  refined  for  ISP  status  are  pDISP  for  proposed  draft  ISP  and  DISP  for  draft  ISP. 

ISO/IEC.  ISO/IEC  is  a  voluntary,  nontreaty  organization  that  develops  standards  in 
many  areas  that  facilitate  the  international  exchange  of  goods  and  services.  The  members  of 
ISO/IEC  are  organizations  chosen  by  the  participating  nations  and  nonvoting,  observer 
organizations.  Most  ISO/IEC  members  are  government  standards  institutions  or  organizations 
incorporated  by  public  law.4 

ISO/IEC  is  organized,  under  die  administrative  arm  of  the  Central  Secretariat,  as  a  group  of 
technical  committees  chartered  to  produce  standards  in  various  areas.  The  committee  t  relevant 
to  this  work  is  the  JTC1  of  ISO/IEC  (formerly,  TC97  on  Information  Processing  Systems).  JTC1 
is  organized  into  subcommittees  and  working  groups  that  actually  produce  the  standards.  The 
work  related  to  OSI  is  carried  on  by  subcommittees  SC6  (lower  layers)  and  SC21  (upper  layers). 
More  specifically,  the  working  groups  of  prime  interest  are: 

•  SC6 — Telecommunications  and  Information  Exchange  Between  Systems 

WG1 — Data  Link  Layer 

WG2 — Network  Layer 

WG3 — Physical  Layer 

WG4 — Transport  Layer 

WG5 — Private  Integrated  Services  Networking 

•  SC18 — Text  and  Office  Systems 

•  SC21 — OSI,  Data  Management,  and  Open  Distributed  Processing 

WG1 — OSI  Architecture 

-  WG3— Database 

WG4 — OSI  Management  and  OSI  Directory 

WG5 — Specific  Application  Services  and  Protocols  (now  merged  with  WG6  into 
WG8) 

WG6 — Session,  Presentation,  Common  Application  Service  Elements,  and 
Upper  Layer  Architecture  (now  merged  with  WG3  into  WG8) 

WG7 — Open  Distributed  Processing 

WG8 — OSI  Upper  Layers  (formerly  WG5  and  WG6) 

-  WG9 — Testing 

•  SC22 — Programming  Languages 

•  SC27 — Common  Security  Techniques  for  Information  Technology  Applications 

WG 1 — Secret  Key  Algorithms  and  Applications 

WG2 — Public  Key  Cryptosystems  and  Modes  of  Use 

WG3 — Use  of  Encipherment  Techniques  in  Communication  Architectures. 


4  For  example,  tfae  member  bodies  from  the  FR,  GE,  UK,  and  US  arc  the  Association  Francaise  de  Normalization 
(AFNOR),  Deutsches  Institute  fur  Nonnung  (DIN),  British  Standards  Institute  (BSI),  and  American  National 
Standards  Institute  (ANSI),  respectively.  Other  member  bodies  are  identified  in  Appendix  F. 
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At  its  March  1993  Plenary  in  Berlin,  JTC1  agreed  to  a  revised  title  and  scope  of  SC21. 
Formerly  called  Information  Retrieval,  Transfer,  and  Management  for  OSI,  the  new  title  is  Open 
Systems  Interconnection,  Data  Management  and  Open  Distributed  Processing.  The  new  scope  is 
as  follows  [Ref.  SC21  N  7720  1993]: 

•  Standardization  of  protocols,  services,  interfaces,  and  information  objects,  and  of 
related  reference  models  covering  the  areas  of  OSI;  management  of  data  and 
information  resources  in  both  local  and  distributed  processing  environment;  open 
distributed  processing;  security  and  management  aspects  related  to  these  areas;  and  the 
relationships  among  these  areas. 

•  Standardization  of  related  conformance  testing  methodologies,  description  languages 
and  techniques,  and  registration  procedures. 

Now  that  the  fundamental  lower  layer  standards  developed  by  SC6  are  in  place,  SC21  is 
the  more  active  of  the  two  subcommittees;  a  summary  of  the  ongoing  projects  and  expected 
completion  dates  of  standards  now  in  development  is  given  in  Appendix  G.  SC6  is  active  in 
security  and  management  for  the  lower  layers,  as  well  as  continuing  work  in  standardization  of 
new  subnetwork  technologies  and  interworking  of  subnetworks.  SC  18  works  on  document 
standards  and  SC22  works  on  programming  language  standards,  while  SC24  concentrates  on 
computer  graphics  (discussed  in  Chapter  11).  SC27  on  Security  Techniques  is  of  interest  to  the 
security  services  discussed  in  Chapter  8.  Standards  from  all  these  groups  are  included  in  the  lists 
provided  in  Appendixes  D  and  E.  The  detailed  program  of  SC21  is  summarized  in  Appendix  G.5 

ITU-TS.  The  ITU-TS  [formerly  the  International  Telephone  and  Telegraph  Consultative 
Committee  (CCITT)  and  International  Radio  Consultative  Committee  (CCIR)]6  is  one  of  three 
sectors  of  the  International  Telecommunications  Union  (ITU),  a  United  Nations  treaty 
organization.  The  other  two  sectors  of  the  ITU  are  Radiocommunication  and  Telecommunication 
Development  ITU-TS  carries  out  the  standardization  role  of  the  ITU.  It  is  responsible  for 
"studying  technical,  operating,  and  tariff  questions  and  adopting  recommendations  on  them  with  a 
view  to  standardizing  telecommunications  on  a  worldwide  basis."  ITU-TS  assumes  the 
standardization  work  of  the  former  CCITT,  together  with  some  related  work  transferred  from  the 
CCIR.  However,  the  former  CCITT  work  aimed  at  aiding  developing  countries  (e.g.,  the  Special 
Autonomous  Groups)  will  now  be  done  in  ITU’s  Telecommunication  Development  Sector. 

The  members  of  ITU-TS,  because  it  is  a  sector  of  a  treaty  organization,  are  governments. 
Normally,  the  members  of  the  ITU-TS  are  the  national  post,  telephone,  and  telegraph  (KIT  ) 
administrations.7  ITU-TS  is  organized  into  IS  study  groups  (SGs).  There  are  three  areas  of 
activity  concerned  with  OSI  matters:  data  communications,  telematic  services,  and  integrated 
services  digital  networks  (ISDNs).  Work  in  ITU-TS  is  focused  on  specific  formal  questions 


5  The  ISO  Technical  Programme,  published  in  January  and  July,  lists  OX  DISs,  draft  technical  reports  (DTRs), 
DADs,  and  DAMs  in  technical  committee  order.  Each  entry  includes  the  target  date,  edition,  title,  and  stage 

number. 

6  At  the  1992  Additional  Plenipotentiary  Conference  in  Geneva,  major  changes  were  made  to  the  Constitution  and 
Convention  of  the  International  Telecommunication  Union  (ITU).  As  a  consequence,  the  work  formerly  done 
by  the  CCITT  will  be  carried  out  in  the  Telecommunication  Standardization  (TS)  sector  of  the  ITU.  The 
CCITT  Secretariat  has  been  replaced  by  the  Telecommunication  Standardization  Bureau.  The  CCITT  Plenary 
Assembly  has  been  replaced  by  the  World  Telecommunication  Standardization  Conference  (WTSC).  The  new 
Constitution  and  Convention  will  eater  into  force  on  1  July  1994,  however,  the  provisions  relating  to  the  new 
structure  and  working  methods  are  applicable  as  hum  1  Much  1993.  [Ref.  SC21 N  7749 1993] 

7  For  example,  the  representation  for  the  United  States  is  from  the  Department  of  State. 
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posed  at  the  beginning  of  the  study  period.  In  the  three  areas  concerned  with  OSI  matters,  the 
work  directly  involves  six  SGs:8 

•  SG  1  on  the  operational  aspects  of  telematic  services 

•  SG  7  on  data  networks  and  open  system  communications 

•  SG  8  on  terminal  equipment  recommendations  for  the  telematic  services 

•  SG  1 1  on  switching  and  control  signaling  for  telephony 

•  SG  13  on  digital  networks  in  general  and  ISDN  in  particular 

•  SG  14  on  data  transmission  over  the  telephone  network. 

Within  the  ITU-TS,  the  Telecommunication  Standardization  Bureau  replaces  the  CC1TT 
Secretariat  The  Telecommunication  Standardization  Advisory  Group  (TSAG),  which  will  meet 
yearly  has  been  established  to: 

•  Review  priorities  and  strategies 

•  Review  progress  in  the  implementation  of  the  work  program 

•  Provide  guidelines  for  the  work  of  study  groups 

•  Recommend  measures  to  foster  cooperation  and  coordination  with  other  standards 
bodies,  with  the  Development  and  Radiocommunication  Sectors,  and  with  the 
Strategic  Planning  Unit  in  the  General  Secretariat 

Documents  produced  by  ITU-TS  are  called  recommendations,  not  standards;  the  term 
recommendation  is  used  because  ITU-TS  does  not  have  the  authority  of  a  standards  body  nor  of  its 
representative  governments  to  prescribe  implementation.  Every  4  years,  the  ITU-TS  holds  a 
World  Telecommunication  Standardization  Conference  (WTSC)  (formerly  the  CCITT  Plenary 
Assembly)  that  establishes  the  work  program  for  the  next  4  years.  This  work  program  is 
composed  of  questions  submitted  by  the  SGs  based  on  requests  made  by  the  various  member 
organizations.  The  first  WTSC  (tenth  CCITT  Plenary)  was  held  1-12  March  1993  in  Helsinki, 
Finland.  The  1993-1996  work  plan  for  ITU-TS  Study  Group  (SG)  7  on  Data  Networks  and  Open 
System  Communications,  which  has  overall  responsibility  for  technical  collaborative  work  with 
ISO/IEC  JTC1,  is  reproduced  in  Section  2  of  Appendix  G.  Of  particular  interest  to  JTC1  are  the 
following  ITU-TS  questions  (a  complete  list  of  open  and  recently  closed  questions  for  JTC1/SC21 
is  provided  in  Appendix  G): 

•  Q  5/7,  Multicast 

•  Q 13/7 ,  OSI  Systems  Management 

•  Q 14/7,  Message  Handling  Systems 

•  Q 15/7,  Directory  Systems 

•  Q 16/7,  Reference  Model  and  Components  for  Open  Distributed  Processing 

•  Q 17/7,  Testing  of  Data  Communications  Protocols 

•  Q 19/7,  OSI  Architecture 

•  Q  20/7,  Security  Services,  Mechanisms,  and  Protocols  for  ITU-TS  Applications 

•  Q  21/7,  OSI  Application  Layer 

•  Q  22/7,  OSI  Presentation  and  Session  Layers 

•  Q  23/7,  OSI  Transport  and  Network  Layers 

•  Q  24/7,  OSI  Data  Link  and  Physical  Layers. 


8  Prior  to  1993,  roman  numerals  were  used  to  identity  study  groups  in  CCITT. 
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At  the  end  of  the  4-year  period,  each  study  group  prepares  draft  recommendations  in 
answer  to  these  questions  and  submits  them  to  the  new  WTSC.  If  the  WTSC  approves  these 
recommendations,  the  drafts  are  published  as  ITU-TS  Recommendations.  The  most  recent  study 
period — 1989  to  1992 — ended  in  April  1992  and  SG  7  endorsed  72  new  or  revised 
recommendations.  In  urgent  situations  (e.g.,  standardization  of  ISDN),  the  drafts  can  proceed 
through  a  special  balloting  procedure  to  become  a  ITU-TS  Recommendation  before  the  normal 
4-year  period  has  expired.  The  new  series  of  recommendations,  when  published,  supersedes  the 
recommendations  from  all  previous  study  periods.  Previously,  all  recommendations  produced  in 
the  same  study  period  were  bound  in  books  of  the  same  color.  For  example,  the  1984 
recommendations  were  known  as  the  "Red  Books"  and  the  1988  recommendations  were  known  as 
the  "Blue  Books."  ITU-TS  has  discontinued  this  practice  [Ref.  JTC1  N  1763  1992]  and,  as  of 
1989,  each  recommendation  will  be  published  as  a  separate  brochure.9  Wherever  possible  these 
are  adopted  as  ISO  standards.10 

An  information  exchange  system  called  TELEDOC  is  being  developed  in  three  phases  by 
ITU  headquarters  for  the  exchange  of  information  and  documents  between  ITU-TS  and  its 
members.  During  the  first  phase,  users  will  have  access  to: 

•  Circulars 

•  Collective  letters 

•  Lists  of  contributions  and  delayed  contributions 

•  Lists  of  study  group  reports 

•  Lists  of  ITU-TS  recommendations 

•  Summaries  of  new  or  revised  recommendations  approved  under  ITU-TS  Resolution 
No.  2 

•  ITU-TS  meeting  schedule  and  information  concerning  study  groups. 

At  present,  TELEDOC  documents  are  available  only  in  ASCII.  Phases  2  and  3  are  being 
developed  and  were  expected  to  become  operational  in  1993.  Members  will  then  be  able  to  access 
the  text  of  ITU-TS  recommendations.  In  addition,  ITU  plans  to  make  available  on  CD-ROM  the 
complete  set  of  all  recommendations  by  the  end  of  1993.  [Ref.  SC21  N  7490 1992] 

A  Guide  for  ITU-TS  and  ISO/IEC  JTCI  Cooperation  has  been  developed  by  the 
Collaborative  Group  on  Procedures  for  ITU-TS  and  ISO/IEC  JTCI  Cooperation.  The  most  recent 
version  is  SC21  N  7747,  April  1993. 


9  Rapid  progress  in  telecomm unicaboo  technologies  and  services  has  led  to  a  dramatic  increase  in  the  number  and 
volume  (since  1980,  the  volume  has  almost  doubled  every  4  years)  of  CCITT  Recommendations,  resulting  in 
delays  to  produce  the  entire  set  every  4  years.  CCITT  concluded  an  unsuccessful  experiment  of  electronically 
distributing  their  recommendations  on  the  Internet  in  December  1991.  Instead,  it  is  now  publishing  each 
recommendation  as  a  separate  brochure  and  will  publish  a  two-part  Catalogue  of  Recommendations.  Part  1  will 
consist  of  new  and  revised  recommendations  approved  and  published  under  the  new  system  (updated  and 
imbtifhfrf  every  6  months).  Put  2  will  be  the  complete  and  detailed  list  of  all  CCITT  recommendations  as 
currently  published  in  the  Blue  Book.  In  May  1992,  SC21  requested  national  body  comment  on  whether  the 
catalogue  that  CCITT  is  developing  satisfies  their  requirements.  [Ref-  SC21  N  7132  1992] 

10  Until  recently,  CCITT  recommendations  were  available  in  the  United  States  from  Omnicom,  Inc,,  115  Park  St 
SE,  Vienna,  VA  22180-4607, 1-800-Omnicom.  Phillips  Publications  in  Potomac,  Maryland,  has  taken  over 
for  Omnicom  but  uses  the  same  phone  number. 
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X/Opefc  X/Open  consists  of  a  staff  of  program  managers  and  marketing  managers  and 
four  groups  of  customers: 

•  X/Open  Corporate  members — system  manufacturers  who  provide  products  and 
services  of  over  $1  billion  annually 

•  The  System  Vendor  Council — system  vendors  who  provide  products  and  services  of 
less  than  $1  billion 

•  The  Independent  Software  Vendor  Council — software  vendors  such  as  UNIX 
International  (UI)/UNIX  Systems  Laboratories  (USL) 

•  The  User  Council — users  who  represent  large  purchasers  of  these  services. 

X/Open  funds  a  technical  program  based  on  the  wishes  of  the  Corporate  Members  since 

they  provide  the  overwhelming  majority  of  X/Open's  operating  budget  Specifications  ate 
sponsored  by  these  manufacturers  for  inclusion  in  the  X/Open  suite  of  specifications.  Some 
specifications  are  obtained  in  whole  from  other  parties  and  "fast-tracked."  In  this  case,  the 
specification  is  sent  to  representatives  of  each  Corporate  Member  and  comments  on  the 
specifications  are  collected  and  "resolved."  These  companies  then  vote  on  whether  the 
specification  should  become  part  of  the  X/Open  specification.  An  example  of  a  fast-tracked 
specification  is  the  Phillips  CD-ROM  specification.  Fast-tracked  specifications  may  be  offered  by 
consortia  in  areas  related  to  computer  systems  such  as  X.400  APIs,  user  interfaces,  etc. 

A  specification  that  is  not  fast-tracked  is  referred  to  an  X/Open  working  group  for 
development  One  of  the  most  important  working  groups  has  been  the  Transaction  Working 
Group.  The  working  groups  meet  four  to  six  times  per  year  and  attempt  to  adapt  (or  more  rarely 
develop)  a  specification  that  is  suitable.  The  "new  specification"  is  studied  by  all  of  the  X/Open 
Stakeholders,  who  then  vote  on  acceptance.  Again,  a  large  fraction  of  the  membership  of  the 
system  manufacturers  is  required  for  acceptance. 

Legal  rights  to  distribute  the  specifications  remain  with  X/Open.  If  these  rights  cannot  be 
obtained,  X/Open  will  not  utilize  its  resources  in  promoting  the  specifications.  X/Open  "brands" 
products  complying  with  its  specifications.  In  order  to  determine  compliance,  X/Open  has  made 
significant  investments  in  developing  verification  suites  that  ensure  that  an  operating  system  and 
command  sequence  is  compliant 

TSGCE.  TSGCE  develops  and  maintains  technical  standardization  agreements 
(STANAGs)  for  NATO.  TSGCE  has  a  number  of  subgroups  and  project  groups  working  on 
standards.  For  example,  TSGCE  SG9  has  responsibility  for  the  NATO  OSI  Reference  Model  and 
for  developing  OSI  and  ISDN  STANAGs  and  profiles.  Appendix  F  lists  the  various  subgroups 
and  project  groups,  and  includes  an  organizational  chart  for  NATO  bodies  in  the  fields  of 
communication  and  information  systems.11  Chapter  18  provides  an  overview  of  the  proposed 
reorganization  of  the  TSGCE,  and  Chapters  17  and  18  describe  the  work  of  TSGCE  in  areas 
related  to  information  systems. 

Organizations  Producing  Standardized  Profiles.  Three  international  regional 
workshops  of  government  and  industry  groups  interested  in  implementation  have  been  established 
to  promote  OSI  and  develop  profiles.  A  Regional  Workshop  Coordinating  Committee  (RWCC) 
promotes  dialog  and  harmonization  among  these  workshops.  The  goal  of  the  workshops  is  to 
define  standards  profiles  that  will  ensure  the  interoperability  of  products  from  different  vendors. 


1 1  NATO  STANAGs  are  listed  in  NATO  Standardization  Agreements  and  Allied  Publications,  AAP-4  (1990), 
which  is  available  (as  are  ibe  STANAGs)  from  the  NATO  Sutvegistry  at  national  MODs. 
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The  European  Workshop  for  Open  Systems  (EWOS)  promulgates  harmonized  technical  proposals 
for  functional  profiles  of  OSI  standards  and  corresponding  conformance  test  specifications.  The 
Asia-Oceania  Workshop  (AOW)  also  prepares  technical  proposals  for  standardized  profiles.  The 
most  active  AOW  participant  is  Japan.  The  OSE  Implementor's  Workshop  (OIW)  provides 
American-hemisphere  input  to  the  standardization  of  profiles.  The  workshop  is  hosted  by  NIST. 
The  recommendations  of  this  workshop  form  the  basis  for  a  multinational  OSI  specification,  called 
Industiy/Govemment  Open  Systems  Specification  (IGOSS),  which  will  become  the  basis  for  the 
US  and  Canadian  government  open  systems  interconnection  profile  (GOSIP)  (see  Sections  16.1.3 
and  16.1.7). 

Data  Communications  Protocol  Standards  (DCPS)  Technical  Management 
Panel  (DTMP).  The  US  DoD  DTMP  manages  technical  activities  within  the  DCPS  area.  It  is 
concerned  with  the  protocols  required  for  information  transfer  on  computer-to-computer  networks. 
One  of  its  primary  missions  is  to  manage  and  coordinate  DoD  representation  to  and  coordination 
with  US  national,  international,  and  commercial  standards  bodies  for  the  purpose  of  influencing 
those  bodies  to  incorporate  military  features  in  their  base  standards  and  profiles.  It  also  develops 
coordinated  DoD  positions  and  recommendations,  develops  draft  standards,  prepares  DCPS 
documents  to  support  the  acquisition  process,  and  presents  appropriate  issues  and  products  to  the 
Standards  Coordinating  Committee  (SCC)  of  the  DISA  Center  for  Standards  (CFS). 

The  DTMP  has  the  following  fifteen  approved  standardization  projects  [Ref.  Curcio  1994]: 

•  DoD  Standardized  Profiles  for  Message  Handling  Systems 

•  Network  Management  (NM)  Standards  for  DoD  Communications 

•  DoD  DCPS  Technical  Reference  Model 

•  Military  Handbook  829  (MIL-HDBK-829) 

•  Validation  Plan  for  Military  Features  in  GOSIP  Protocols  and  Architectures 

•  DoD  Conformance/Interoperability  Test  Plan  for  Military  Features  in  GOSIP  Protocols 
and  Architectures 

•  Multicasting  Standards  Development  for  OSI 

•  Defense  Standardized  Profile  for  Secondary  Imagery  System 

•  OSI  Enhanced  Communication  Functions  and  Facilities  (ECFF)  for  the  Lower  Layers 

•  Wireless  Connectivity  over  Local  Area  Networks 

•  Security  Labeling  Options  Protocol 

•  Incorporation  of  Secure  Data  Network  Standards  (SDNS)  Protocols  into  OSI 

•  Interim  Joint  Task  Force  Data  Communications  Profile 

•  Development  of  a  Security  Standards  Framework 

•  Influence  ISO  Generic  Upper  Layer  Security  (GULS)  Development 

These  projects  are  assigned  to  the  following  seven  working  groups  in  the  DTMP 
[McLane  1992;  Curcio  1994]: 

•  WG1,  Lower  Layers 

•  WG2,  Upper  Layers 

•  WG3,  Security 

•  WG4,  Network  Management 

•  WG5,  Architecture 
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•  WG6,  Registration  (inactive  as  of  October  1993) 

•  WG7,  Testing. 

2.4  Proposed  Definitions  for  Terms  Used  in  Information  System  Service 
Standardization 

Table  1  provides  the  definitions  of  a  number  of  technical  terms  used  in  this  document  and 
elsewhere  in  discussing  information  system  and  CCIS  standardization.  These  definitions  were 
derived  from  many  sources  and  proposed  by  the  US  Corporate  Information  Management  (CIM) 
Standards  Office.  [Ref.  Keane  1991] 

Table  1.  Definitions  of  Terms  for  Information  System  Service  Standardization 


Application  Software  Interoperability:  Tha  ability  to  have  application  software  operating  on  heterogeneous 
hardwara/aoftwara  platforms  cooperate  in  performing  some  user  function.  (Source:  NIST  with  modification) 

Basic  Interoperability:  The  exchange  of  data  that  preserves  the  meaning  and  relationship  of  the  data  exchanged. 
(Source:  ATCCIS) 

Buffar/pataway:  Software  or  hardware  used  to  compensate  for  a  difference  in  rate  of  flow  of  data  or  time  of 
occurrence  of  events  or  differences  in  protocol  or  in  data  representation  when  transferring  data  from  one  system 
to  another.  (Preliminary.  Source:  NATO  Interoperabity  Management  Plan  (NIMP),  EdKion  2) 

Compatibility:  The  capability  of  two  or  more  Kerns  or  components  of  equipment  or  materiel  to  exist  or  function  in  the 
same  system  or  environment  without  mutual  interference.  [Source:  Joint  Chiefs  of  Staff  (JCS)  PUB  1] 

Information  system  interoperability.  The  ability  of  systems  to  exchange  data,  in  a  timely  manner,  in  support  of  a 
user-defined  business  decision  process,  and  to  preserve  the  meaning  and  relationships  of  the  data  exchanged. 
The  degree  of  interoperability/information  exchange  (e.g.,  manual,  limited  automated,  fuly  automated)  is  to  be 
determined  by  the  system  users  and  developers. 

Interoperability:  The  ability  of  systems,  units,  or  forces  to  provide  services  to  and  accept  services  from  other 
systems,  units,  or  forces  and  to  use  the  sendees  so  exchanged  to  enable  them  to  operate  effectively  together. 
(JCS  PUB  1) 

Open  Specifications:  Public  specifications  that  are  maintained  by  an  open,  public  consensus  process  to 
accommodate  new  technologies  over  time  and  that  are  consistent  with  international  standards.  (Source:  IEEE 
POSIX  1003.0) 

Open  System:  A  system  that  implements  sufficient  open  specifications  for  interfaces,  services,  and  supporting 
formats  to  enable  properly  engineered  applications  software:  to  be  ported  with  minimal  change  across  a  wide 
range  of  systems;  to  interoperate  with  other  applications  on  local  and  remote  systems;  and  to  interact  with  users 
in  a  style  that  facilitates  user  portability.  (Source:  IEEE  POSIX  1003.0) 

Open  System  Environment  (OSE):  The  comprehensive  set  of  interfaces,  sendees,  and  supporting  formats,  plus 
user  aspects,  for  interoperability  or  for  portability  of  applications,  data,  or  people,  as  specified  by  information 
technology  standards  and  profiles.  (Source:  ISO) 

Portability:  The  ability  to  use  application  software  and  data  on  heterogeneous  hardwara/software  platforms. 
(Source:  NIST) 

Scalability:  The  ability  to  use  the  same  application  software  on  many  different  classes  of  hardwara/software 
platforms,  from  personal  computers  to  supercomputers.  (Source:  NIST) 

Taxonomy:  A  scheme  for  describing  the  orderly  classification  of  objects  according  to  their  presumed  natural 
relationship.  The  classification  scheme  is  a  system  of  signs  and  symbols  (the  vocabulary)  that  includes  rules  for 
the  formation  and  transformation  of  admissible  expressions  (the  grammar). 

Technical  Architecture:  A  set  of  standards  such  that  information  systems  built  to  the  standards  are  inherently 
interoperable.  The  degree  of  interoperability  is  to  be  specified  by  the  functional  user  as  part  of  the  requirements 
definitio  >  process.  (Preliminary.  Source:  Suggested  by  DMR  and  work  in  ATCCIS) 

Source:  CIM  Twminohgy,  Private  communication  from  Mr.  John  Keane,  US  DoD  CIM  Standards  Office.  CIM/XI, 

16  July  1691,  UNCLASSIFIED. 


2.5  Assessments  of  Standards 

While  many  discussions  on  open  systems  focus  on  common  operating  systems  (instead  of 
standard  interfaces)  and  portability,  the  primary  concerns  of  CCIS  users  are:  (1)  interoperability 
across  heterogeneous  systems,  (2)  flexible  architectures  for  organization-wide  open  systems 
computing,  (3)  heterogeneous  networked  database  access,  and  (4)  integrated  open  and  proprietary 
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network  management.  Standards  for  interoperability  therefore  need  to  be  selected  to  support  areas 
such  as  network  connectivity,  data  sharing,  multi-client  application  support,  and  integrated  systems 
management  [Ref.  RNLA  1994,  p.  22]  These  are  the  areas  of  services  for  which  standards  are 
described  in  this  document 

There  are  a  number  of  competing  forces  vying  for  control  of  the  standards  world.  Users 
want  everything  standardized  before  they  buy  anything.  Vendors  want  everything  else 
standardized  except  the  area  in  which  they  operate,  so  their  products  are  not  governed  by 
standards,  but  all  the  products  they  depend  upon  are  so  governed.  Areas  that  require  more 
investment  by  users  need  more  stability  before  being  standardized.  Rapidly  changing  technologies 
may  never  be  standardized.  Vendors  that  dominate  a  product  area  have  no  interest  in  open 
standards,  and  without  their  support,  open  standards  have  a  very  hard  time  catching  on  in  the 
marketplace.  Some  areas  demand  international  acceptance  of  standards  and  some  do  not 

The  result  of  all  this  is  a  very  delicate  balance  among  openness,  maturity,  and  timing.  Hie 
standards  community  is  grappling  with  this  balance  with  the  result  that  some  of  the  standards 
processes  are  undergoing  revision.  ISO's  dominance  as  the  primary  keeper  of  the  seal  of  approval 
of  international  standards  is  being  threatened.  As  noted  above,  ISO  is  searching  for  a  faster  route 
to  consensus  to  maintain  its  role  in  the  international  arena.  At  the  same  time,  X/Open  is  expanding 
its  role  as  a  link  between  consortia  and  the  international  community  as  a  mechanism  for  gaining 
quicker  acceptance  of  working  standards  in  both  worlds.  And  everyone  is  working  hard  to  be  a 
team  player  by  maintaining  liaison  with  everyone  else.  However,  in  areas  where  one  vendor  has 
established  a  position  of  architectural  control,  they  are  not  giving  it  up,  leaving  users  to  wonder  if 
standardization  efforts  in  those  areas  will  ever  pay  off. 

Where  possible.  Chapters  4  to  14  provide  assessments  of  the  status  of  the  standards  in  the 
11  service  areas.  The  main  assessments  appear  at  the  ends  of  the  chapters.  Summary 
assessments,  derived  from  the  NIST  Applications  Portability  Profile  (APP)  [Ref.  NIST  1993],  are 
provided  in  the  beginning  of  most  of  the  chapters  in  die  form  shown  in  Figure  3.  Note,  however, 
that  such  assessments  change  quickly  as  products  emerge  and  gain  widespread  use. 

LOC  -  Laval  at  aonaanoua 
MV  -  Product  aval  ah  tty 
CUP  -  CompManaaa 
MAT  —  Maturity 
•TV  —  StabMtty 
DFU  -OataataiiMsa 
ML  -  ProblamaMrwUaSona 


Figure  5.  Example  Summary  Asaassmant 

The  notations  of  Figure  5  are  defined  as  follows  [Ref.  NIST  1993]: 
a  Level  of  consensus.  A  low  evaluation  is  given  to  specifications  that  are  proprietary  or 
are  used  by  a  very  limited  or  specialized  group  of  users,  such  as  vendor  consortia;  a 
high  evaluation  is  given  for  a  specification  that  has  already  become  a  national  or 
international  standard;  average  evaluations  are  assigned  for  pubic  domain 
specifications  that  are  not  standard,  or  that  may  be  in  the  process  of  becoming  a 
standard  (i.e.,  standards  committee  work-in-progress),  or  that  are  widely  available 
across  various  hardware/software  platforms. 
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Product  Availahilitv  A  low  evaluation  is  given  to  specifications  for  which  only  a  very 
few  proprietary  products  are  available;  high  evaluations  are  given  to  specifications  for 
which  there  is  a  wide  variety  of  products  available  from  various  vendors  across 
different  application  platforms;  average  evaluations  are  assigned  to  specifications  that 
may  be  proprietary  but  have  many  products  available  from  a  variety  of  vendors,  or  that 
are  public  domain  specifications  with  products  readily  available. 

Completeness.  A  specification  is  evaluated  on  the  degree  to  which  it  defines  and 
covers  key  features  necessary  in  supporting  a  specific  functional  area  or  service.  For 
example,  a  network  security  specification  that  includes  all  of  the  components  described 
would  be  evaluated  higher  than  others  that  do  not  include  all  of  the  features. 

Maturity.  According  to  the  underlying  technology  of  a  specification,  a  high  evaluation 
indicates  that  it  is  well  understood  (e.g.,  a  reference  model  is  well-defined,  appropriate 
concepts  of  the  technology  are  in  widespread  use,  the  technology  may  have  been  in 
use  for  many  years,  a  formal  mathematical  model  is  defined).  A  low  evaluation 
indicates  that  it  may  be  based  on  technology  that  has  not  been  well  defined  and  may  be 
relatively  new. 

Stability.  A  high  evaluation  means  that  the  specification  is  very  stable;  no  changes  are 
expected  within  the  next  2  years.  A  low  evaluation  indicates  that  significant  or 
numerous  changes  are  expected  within  a  relatively  short  time  (1  to  2  years),  or  that 
incompatibilities  exist  between  current  and  expected  releases  of  the  specification.  An 
average  evaluation  is  given  to  those  specifications  that  may  have  known  changes 
forthcoming  to  replace  features  in  tire  existing  specifications. 

De  facto  usage.  This  evaluation  criterion  estimates  the  likelihood  that  a  vendor  will 
independently  propose  products  that  conform  to  this  specification  whether  or  not  a 
reference  specification  is  stated  in  the  procurement  documents.  A  high  evaluation 
indicates  that  most  proposed  products  will  conform  to  the  specification.  A  low 
evaluation  indicates  that  it  is  unlikely  that  the  vendor  will  propose  products  based  on 
the  specifications.  An  average  evaluation  indicates  that  vendors  are  just  as  likely  to 
propose  products  based  on  the  specifications  as  not  (i.e.,  no  clear  determination 
exists).  In  the  cases  of  low  or  average  evaluations,  it  is  imperative  that  users  include  a 
specification  in  procurement  documentation.  A  low  evaluation  does  not  necessarily 
mean  that  products  implemented  on  the  specification  do  not  exist  It  can  also  mean  that 
some  vendors  would  rather  provide  products  that  are  not  based  on  the  recommended 
specifications,  such  as  proprietary  implementations. 

Problems/limitations.  Lower  evaluations  are  assigned  to  specifications  with  severe 
restrictions  on  use  or  capabilities  (e.g.,  licensing  restrictions)  or  with  known  problems 
that  tend  to  be  too  difficult  or  too  numerous  to  overcome  (e.g.,  new  releases  of  the 
specification  are  not  compatible  with  previous  releases,  or  not  enough  is  covered  in  the 
standard  to  be  useful).  An  average  evaluation  is  given  to  those  specifications  that 
require  some  minor  additional  facility  in  order  to  be  fully  effective  in  their  intended 
environment  This  additional  facility  may  be  provided  by  a  related  standard  or  other 
specification. 
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3.  ARCHITECTURES,  FRAMEWORKS,  AND  REFERENCE  MODELS 

This  chapter  describes  high-level  generic  architectures,  frameworks,  and  technology 
reference  models. 

3.1  Terminology 

The  terms  architecture,  framework,  and  reference  model  have  been  used  in  so  many 
overlapping  ways  that  the  only  way  to  know  what  they  mean  in  a  specific  context  is  to  ask  the 
writer  or  speaker.  Within  this  document,  these  terms  have  the  following  meanings: 

Architecture  The  high-level  structure  of  the  systems  in  a  specific  group.  The  architecture 
should  define  all  structural  elements  that  are  to  be  common  to  all  the  systems 
in  the  group,  but  that  is  not  part  of  the  definition. 

Framework  A  software  product  that  forms  the  basis  of  a  more  complete  product,  with 

the  expectation  that  the  remaining  components  will  fit  easily  into  the  overall 
system.  A  software  engineering  environment  (SEE)  framework  is  an 
example  of  this  type  of  framework.  It  may  provide  no  functionality  directly 
accessible  to  a  user,  but  it  is  expected  that  die  completed  SEE  will  provide 
numerous  tools  that  aid  software  developers.  The  notion  of  a  framework 
implies  that  the  framework  product  contributes  in  some  way  to  the 
integration  of  the  other  components.12 

Reference  Model  A  specification  for  the  structure  of  a  technology  suitable  for  identifying 
required  standards  for  that  technology.  For  example,  the  Basic  Reference 
Model  for  Open  System  Interconnection  defines  the  structure  of  networking 
technology  as  layers  with  a  high-level  definition  of  the  function  of  each 
layer,  but  without  defining  the  standards  for  either  die  service  definitions  or 
the  protocols  of  any  layer.  The  intent  to  serve  as  a  structure  for  standards 
development  is  part  of  die  definition  of  a  reference  model 

The  US  DoD  has  defined  a  high-level  document  to  promote  information  system 
standardization,  DoD  Technical  Architecture  Framework  for  Information  Management  (TAFIM) 
[Ref.  TAFIM  1993].  Under  the  definitions  given  above,  this  document  is  neither  a  framework  nor 
an  architecture,  but  it  contains  an  architecture  in  Volume  2,  Technical  Reference  Model  (TRM)  and 
Standards  Profile  Summary.  Volume  3  addresses  Architecture  Concepts  and  Design  Guidance. 
Volumes  1  ( Overview )  and  3  provide  guidance  outside  the  realm  of  standardization.  Volume  4  is 
the  Implementation  Manual,  and  Volume  3  is  the  Support  Plan.  Volume  6  is  a  reference  model 
called  an  architecture  [the  DoD  Goal  Security  Architecture  ( DGSA )].  Volume  7  is  Information 
Technology  Standards  Guidance  for  an  Open  System  Environment  (ITSG-OSE).  Volume  8  is  the 
DoD  Human  Computer  Interface  (HCI)  Style  Guide. 

Frameworks  (as  defined  above)  are  not  discussed  further  in  this  chapter.  The  only  known 
efforts  to  develop  standard  frameworks  are  as  the  basis  for  an  SEE.  These  are  discussed  in 
Chapter  4. 

3.2  High-Level  Generic  Architectures 

This  section  discusses  the  following  high-level  generic  architectures:  the  ATCCIS 
architecture,  the  NATO  C3  Architecture,  the  National  Institute  for  Standards  and  Technology 


12  la  ISO,  a  framework  has  more  general  meaning.  Rather  than  a  product,  a  framework  m  ISO  is  a  specification 
that  show*  bow  various  functions  wotk  aad  arc  related  to  other  functions.  Frameworks  exist  for  security 
(ISQffEC  10181)  and  management  (ISCVIEC  10164). 
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(NIST)  Applications  Portability  Profile  (APP),  the  IEEE  Portable  Operating  System  Interface 
(POSIX)  Guide,  and  the  US  DoD  Technical  Reference  Model  (TRM). 

3.2.1  ATCCIS  Architecture 

The  four  ATCCIS  facilities  essential  to  basic  interoperability — the  exchange  of  data  that 
preserves  the  meaning  and  relationships  of  the  data  exchanged — are  the  Data  Management  Facility 
(DMF),  the  Transfer  Facility  (TF),  the  Service  Control  Facility  (SCF),  and  the  System 
Management  Facility  (SMF).  These  four  "Basic  Facilities"  provide  the  three  mechanisms 
necessary  for  basic  interoperability:  providing  end-to-end  transfer  of  data;  managing  the  storage, 
retrieval,  and  interpretation  of  data;  and  managing  the  first  two  mechanisms  as  the  minimum 
capability  to  support  basic  interoperability.  (An  overview  of  the  features  of  the  ATCCIS 
architecture  is  given  in  Appendix  A.) 

The  standards  for  CCISs  addressed  in  this  document  are  not  limited  to  the  Basic  Facilities 
required  for  basic  interoperability.  Capabilities,  such  as  portability  of  applications  software,  that 
support  a  more  general  concept  of  interoperability  constitute  enhanced  interoperability.  These  are 
addressed  in  the  ATCCIS  architecture  in  such  facilities  as  the  Input/Output  Facilities  (IOFs)  that 
provide  interfaces  to  systems  not  conforming  to  the  ATCCIS  architecture;  the  Man-Machine 
Interface  (MMI)  Support  Facility  (MSF)  that  provides  standard  user  interfaces,  and  Application- 
Level  Facilities  (ALFs)  that  provide  common  automated  support  for  various  command  and  control 
functions. 

Five  of  the  groups  of  services  are  essential  to  basic  interoperability  and  thus  to  the  four 
basic  facilities  of  the  ATCCIS  architecture:  data  management  (ATCCIS  DMF),  network  services 
for  OSI  (ATCCIS  TF),  operating  system  interface  services  (ATCCIS  SCF);  and  security  services 
and  system  management  services  (ATCCIS  SMF  and  other  facilities).  The  other  service  areas  will 
provide  for  enhanced  interoperability:  data  interchange  services  and  distributed  computing 
(applicable  to  die  DMF);  user  interfaces  and  internationalization  (applicable  to  the  MSF);  graphics 
services  (applicable  to  the  MSF  and  ALFs);  and  software  engineering  services  (applicable  to  ALFs) 

3.2.2  NATO  C3  Architecture 

The  NATO  C3  Architecture  is  described  in  one  part  of  the  four-part  NATO  Consultation, 
Command  and  Control  (C3)  Master  Plan  [Ref.  NACISC  1989].  Based  on  early  work  contained 
in  the  1980-1982  Architecture  Design  Study  (ADS),  the  ADS  follow-on  studies  (STC  Projects 
85-3  anti  86-1),  and  ATCCIS  Working  Papers  (WP  11,  WP  24,  and  WP  25),  the  NATO  C3 
Architecture  applies  to  the  NATO  Command,  Control  and  Information  System  (NCCIS),  which 
comprises  automated  command  and  control  information  systems  ( ACCISs).  Examples  of  NATO 
ACCISs  are  described  in  Chapter  18. 

The  NCCIS  Architecture  describes  an  automated  CCIS  in  precisely  the  same  terms  used  to 
describe  ATCCIS:  "a  transaction  processing  system  with  a  partitioned,  partially  replicated 
database,  capable  of  supporting  applications,  and  maintaining  a  consistent  interpretation  erf  the  data 
across  organizational  boundaries"  [Ref.  NACISA  1989b].  As  in  ATCCIS,  die  NCCIS  architecture 
employs  the  concept  of  basic  interoperability  to  address:  die  need  to  communicate  so  as  to  permit 
the  exchange  of  data,  and  the  need  to  have  a  common  interpretation  of  the  data  thus  exchanged. 
The  NCCIS  Architecture  identifies  the  following  as  required  to  achieve  basic  interoperability: 
international  OSI  information  exchange  standards,  data  dictionary,  data  model  (defining  logical 
structure  of  data),  and  database  conceptual  schema  (logical  database  design). 
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Hie  NCOS  Architecture  uses  the  concept  of  enhanced  interoperability  to  describe 
interoperability  aspects  that  go  beyond  basic  interoperability.  In  NCOS,  these  apply  only  to 
NATO-owned  systems  for  "higher  degrees  of  interoperability  to  support  other  operational 
requirements,  flexibility,  and  cost  saving."  Examples  of  areas  where  higher  degrees  of 
interoperability  can  be  achieved  in  NCOS  are  common  and  generic  application  programs  and 
human-machine  interface. 

NCOS  identifies  five  major  classes  of  services:  information  exchange,  data  management, 
system  control,  application  support,  and  human-machine  interface  management  In  NCOS  these 
services  are  discussed  as  functions.  The  standards  identified  for  supporting  the  architectures  are 
identical  for  NCOS  and  A7CCIS.13 

3.2.3  IEEE  POSIX  OSE  Reference  Model 

IEEE  P1003.0,  Draft  Guide  to  the  POSTX.  Open  System  Environment  [Ref.  IEEE  1992], 
seeks  to  accelerate  consensus  on  an  open  systems  environment  (OSE)  for  applications  portability 
and  provides  guidance  to  users  on  how  to  develop  applications  profiles.  Chapter  10  discusses  the 
POSIX  effort 

P1003.0  defines  a  POSIX  OSE  Reference  Model  that  is  the  basis  for  the  model  shown  in 
Figure  1  in  Chapter  1.  Both  models  use  the  same  three  high-level  entities:  Application  Software 
Entity,  Application  Platform  Entity,  and  External  Environment  Some  platform  services  are 
included  in  the  application  program  interface  (API)  between  the  first  two  of  these  entities,  and 
others  are  included  in  the  external  environment  interface  (EEI)  between  the  last  two  of  these 
entities.  The  models  differ  primarily  in  the  groupings  of  platform  services  that  make  up  the 
application  platform  entity.  The  POSIX  OSE  Reference  Model  identifies  four  classes  of  APIs 
(system,  communications,  information,  and  human/computer  interaction),  whereas  the  model 
adopted  for  WP  23  is  more  detailed,  defining  1 1  classes:  software  engineering,  user  interface,  data 
management,  data  interchange,  graphics,  network,  operating  system,  security,  system 
management,  distributed  computing,  and  internationalization. 

3.2.4  NIST  Applications  Portability  Profile  (APP) 

Section  15.1.33  discusses  the  APP  developed  by  the  NIST.  The  NIST  approach  to 
applications  portability  is  based  on  an  architectural  approach  that  provides  interfaces  for 
functionality  to  accommodate  a  broad  range  of  applications  requirements.  The  functional 
components  of  the  architecture  are  viewed  as  a  "tool  box"  of  standard  elements  that  can  be  used  to 
develop  and  maintain  portable  applications.  These  tools  are  based  on  an  open  systems  concept  and 
are  required  to  be  developed  as  an  integrated  collection  of  non-proprietary  standards. 

A  full  complement  of  standards  should  be  available  under  the  APP  by  1993.  [Ref.  APP 
1991]  Version  2  of  the  Application  Portability  Profile  ( APP ):  The  U.  S.  Government's  Open 
System  Environment  Profile  OSE/1  was  published  in  May  1993.  It  recommends  standards  and 
specifications,  provides  guidance  in  areas  where  standards  do  not  exist  for  seven  service  areas,  and 
makes  strategic  evaluations  with  respect  to  those  standards.  These  seven  service  areas  are: 
operating  system,  human/computer  interface,  data  management,  data  interchange,  software 
engineering,  graphics,  and  network.  Two  additional  services  areas,  called  integral  supporting 


13  The  survey  of  standards  adopted  for  the  NATO  C3  Architecture  was  primarily  a  set  of  excerpts  from  an  early 
etfitioo  of  WP  25. 
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services,  are  security  and  management  These  service  areas  are  all  based  on  the  high-level  POSIX 
OSE  Reference  Model. 

3.2.5  DoD  Technical  Reference  Model  (TRM)14 

The  US  DoD  has  developed  its  Technical  Reference  Model  (TRM)  for  Information 
Management  to  provide  technical  guidance  for  the  acquisition,  development  and  support  of  DoD 
information  systems  and  associated  infrastructure  systems.  The  TRM,  shown  in  Figure  1  in 
Chapter  1,  provides  the  high-level  relationships  of  the  domain  showing  the  major  service  areas.13 
When  populated  with  specific  standards,  the  model  defines  a  profile  of  technical  standards  that  are 
mandatory  for  DoD  information  systems,  except  those  that  are  specifically  exempted  by  the  US 
Information  Technology  Policy  Board  (ITPB).  The  model,  while  not  a  specific  system 
architecture,  defines  standards  and  guidelines  that  can  be  tailored  and  applied  to  meet  the  needs  of 
specific  mission  areas  (Le.,  mission  or  functional  areas). 

Figure  1  only  depicts  entities,  interfaces,  and  service  areas  and  does  not  imply  relationships 
among  the  service  areas.  The  Technical  Reference  Model  adopts  the  foundation  work  of  IEEE 
POSIX  Working  Group  P1003.0  [ Draft  Guide  to  the  POSIX  Open  System  Environment,  Draft  15, 
IEEE,  June  1992].  The  Technical  Reference  Model  identifies  services  for  the  Application  Platform 
Entity  of  the  POSIX  Open  System  Reference  Model;  identifies  application  program  interfaces 
(APIs)  such  as  system  services,  communications  services,  information  services,  and  human- 
computer  interaction  services  between  die  Application  Platform  Entity  and  the  Application  Software 
Entity;  and  external  environment  interfaces  (EEIs)  such  as  communications  services,  information 
services,  and  human-computer  interaction  services  between  the  Application  Platform  Entity  and  the 
External  Environment  (at  die  bottom  of  the  figure).  The  1 1  service  areas  of  the  TRM  match  the 
eleven  service  areas  treated  in  Chapters  4-14  of  this  document 

Li  April  1993,  the  Department  of  the  Air  Force,  Electronic  Systems  Center  (ESC),  adopted 
a  software  standards  policy  based  on  the  DoD  Technical  Reference  Model  The  ESC  framework 
defines  three  sets  of  standards:  one  for  embedded  systems,  one  for  command  centers,  and  one  for 
management  information  systems.  [Ref.  ESC  1993] 

3.3  Technology  Reference  Models 

The  ISO  and  others  have  developed  several  technology  reference  models  that  are  described 
in  this  document  These  include: 

•  Open  Systems  Interconnection  (OSI)  Reference  Model  (ISO  7498)  (see  Section  9.1) 

•  Open  Distributed  Processing  (ODP)  Reference  Model  (CD  10746)  (see  Section  13.2) 

•  Office  Document  Architecture  (ODA)  Reference  Model  (see  Section  7.1.1) 

•  DoD  Goal  Security  Architecture  (see  Section  1 1.2.4.8) 

•  NIST  User  Interface  Reference  Model  (see  Sections  5.2.6  and  5.3) 

•  Object  Management  Group's  (OMG)  Object  Management  Architecture  (see 
Section  13.3). 


14  WP  25  was  the  survey  of  standards  used  to  define  the  initial  version  of  the  TRM. 

13  US  DoD  components  are  required  to  apply  the  TRM  to  increase  commonality  and  interoperability  across  tbe 
Department,  as  directed  by  the  Director  of  Defense  Information  (DDI)  in  February  1992  [Ref.DDI  1992]. 

Chapter  3  26  Architecture  &  Reference  Models 

UNCLASSIFIED 


UNCLASSIFIED 


4.  SOFTWARE  ENGINEERING  SERVICE  STANDARDS 

This  chapter  identifies  programming  languages,  software 
development  environments,  tool  sets,  process  models,  and 
methodologies,  and  other  software  engineering  service 
standards.  An  overview  of  the  status  of  key  standards  for 
software  engineering  services  is  given  in  Table  2. 

4.1  Requirements  for  Software  Engineering 
Services 

Software  engineering  services  address  the  sets  of  tools 
that  support  requirements  definition,  system  development, 
testing,  maintenance,  and  administration.  They  also  address 
computer-aided  software  engineering  (CASE),  software 
development  environments  and  tools,  and  library  support. 

In  order  to  satisfy  the  overall  requirement  for  using 
COTS/NDI  hardware  and  software,  software  must  be  both 
portable  and  interoperable.  Requirements  for  the  efficient 
production  of  effective  software  dictate  the  use  of  software 
development  environments  and  tools  as  well  as  reuse  libraries. 

As  the  technology  evolves,  needs  for  expert  system  support  in 
the  software  production  process  will  arise. 

4.2  Programming  Languages 

4.2.1  Ada  Programming  Language 

Ada  is  a  programming  language  agreed  to  be  used  within 
NATO  and  the  US  DoD16  as  a  standard,  general-purpose 
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16  DoD  Directive  3405.1  states  that  Ada  is  the  preferred  computer  programming  language  for  all  US  DoD 
applications  except  when  the  use  of  another  higher  order  language  is  most  cost  effective  over  the  application's 
life  cycle.  DoD  Directive  3405.2  mandates  the  use  of  Ada  in  all  computers  integral  to  weapons  systems 
(embedded  systems). 
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high-level  programming  language.  It  was  introduced  in  1979  after  the  US  DoD  became  concerned 
about  the  proliferation  of  computer  languages  it  was  using  and  determined  that  none  of  these 
languages  was  suitable  for  writing  DoD  software.  Ada  uses  the  latest  ideas  in  language  design  and 
a  standard  programming  support  environment  is  suggested.  It  was  adopted  in  1983  as  a  common 
standard  by  ANSI  and  US  Military  Standard  (MIL-STD-1815A)  and  in  November  1985  as  a 
Federal  Information  Processing  Standard  (FIPS  119).  In  1987,  ISO  endorsed  it  as  an  ISO 
standard  (ISO  8652). 

Ada  9X,  the  project  to  revise  ANSI/MIL-STD-1815A  has  officially  entered  the  ISO 
standardization  process  by  being  submitted  for  registration  as  a  CD  in  September  1993.  Balloting 
has  begun.  Ada  9X  was  also  sent  out  for  voting  by  ANSI,  and  DIS  balloting  is  expected  to  begin 
in  January  1994. 

Proposed  DoD  policy  regarding  the  transition  to  Ada  9X  calls  for  a  2-year  period  after  ISO 
approval  when  either  Ada  83  or  Ada  9X  can  be  used.  After  this  2-year  period,  the  use  of  Ada  9X 
will  be  required  for  new  projects.  As  always,  existing  Ada  83  projects  are  free  to  baseline  on  Ada 
83  compilers.  In  addition,  to  hasten  the  transition,  prior  to  ISO  approval  the  use  of  Ada  9X  will  be 
encouraged  for  research  and  development  projects  using  a  compiler  in  beta  testing. 

The  Ada  Semantic  Interface  Specification  (ASIS)  was  developed  to  give  tool  developers 
access  to  the  Ada  syntactic  and  semantic  information  contained  in  Ada  libraries.  ASIS  is  an  open 
standard  that  supports  multiple  CASH  tools,  multiple  Ada  compilation  systems,  and  the  ability  to 
easily  integrate  proprietary  tools.  ASIS  is  an  interface  between  the  Ada  library  produced  by  a 
compiler  for  a  program  and  any  tool  requiring  information  from  that  library. 

4.2. 1.1  Ada  Programming  Support  Environment  (APSE) 

An  APSE  is  an  environment  for  developing  software  systems  written  in  Ada.  At  its  core  is 
a  kernel  APSE  (KAPSE),  which  represents  general  operating  system  services  such  as  file 
management  services  and  process  and  device  control  services,  as  well  as  object  management 
services.  It  is  at  this  level,  as  opposed  to  the  outer  layers,  the  MAPSE  (Minimal  APSE)  and 
APSE,  that  a  common  set  of  interfaces  is  required.  The  MAPSE  consists  of  software  tools  that 
minimally  support  software  development,  such  as  compilers,  editors,  and  linkers,  while  the  APSE 
provides  project-specific  tools  and  services.  APSE  is  the  subject  of  a  special  working  group  in 
TSGCE  (see  Section  17.3). 

4.2. 1.2  Common  APSE  Interface  Set  (CAIS) 

CAIS  provides  a  common  set  of  interfaces  to  the  KAPSE.  The  CAIS  standard  (US  DoD 
MIL-STD- 1 838A,  1989)  defines  a  set  of  interfaces  that  allows  APSE  tools  to  use  common 
operating  services  and  facilities  in  a  standardized  fashion.  The  original  plan  for  the  designing  of 
CAIS  in  the  United  States  called  for  one  set  of  interfaces  to  be  produced  at  the  end  of  4  years’ 
work  (the  original  target  was  1987).  As  pressure  mounted  for  an  earlier  release,  the  Ada  Joint 
Program  Office  (AJPO)  decided  that  a  limited  capability  version  should  be  provided  before  the  full 
CAIS  was  complete. 

The  firt’.>  version  of  CAIS  (US  DoD  MIL-STD- 1838)  was  published  in  October  1986.  It 
was  supposed  to  comprise  only  those  interfaces  common  to  two  different  APSEs  being  developed 
by  the  US  Army  and  the  US  Air  Force:  the  Ada  Language  System  (ALS,  for  the  Army)  and  the 
Ada  Integrated  Environment  (AIE,  for  the  Air  Force).  Because  of  divergent  approaches  at  the 
KAPSE  interface  level  taken  by  the  ALS  and  AIE  contractors,  the  KAPSE  Interface  Team  (KIT) 
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and  the  KAPSE  Interface  Team  from  Industry  and  Academia  (KITIA)  were  formed.  Together,  the 
KIT/KITIA  produced  the  first  version  of  the  CAIS  based  on  the  entity-relation-attribute  (ERA) 
model. 

In  parallel,  the  Requirements  and  Design  Criteria  Working  Group  (RACWG),  composed  of 
KIT  and  KITIA  members,  was  established  in  July  1983  for  the  purpose  of  defining  a  set  of 
requirements  and  criteria  for  the  design  of  a  second  version  of  the  CAIS.  In  1985,  a  contract  was 
awarded  to  SofTech,  Inc.,  to  continue  development  of  this  second  version  of  CAIS  (CAIS-A). 
CAIS-A  was  reviewed  publicly  in  1987  and  was  published  as  a  military  standard  (MIL-STD- 
1838A)  in  April  1989  [Ref.  AJPO  198.  ]. 

There  are  no  plans,  nor  is  a  mechanism  currently  in  place,  to  update  CAIS-A.  While  there 
are  three  implementations  of  CAIS-A,  the  effort  is  generally  suffering  due  to  a  lack  of  commercial 
support 

4.2.2  Pascal  Programming  Language 

Pascal  is  a  computer  programming  language  originally  designed  to  satisfy  two  principal 
aims:  (1)  to  provide  a  language  suitable  for  teaching  programming  as  a  systematic  discipline  based 
on  certain  fundamental  concepts  clearly  and  naturally  reflected  by  the  language  and  (2)  to  define  a 
language  whose  implementations  could  be  reliable  and  efficient  on  then-available  computers.  A 
Pascal  standard  was  adopted  in  1983  as  ANSI  X3.97  and  IEEE  770. 

At  the  same  time  that  the  ANSI/IEEE  Pascal  standard  was  being  developed,  the  British 
Standards  Institution  (BSI)  sponsored  an  ISO  draft  proposal  for  Pascal.  In  1983,  ISO  adopted 
Pascal  as  a  standard  (ISO  7185),  endorsing  British  Standard  (BS)  6192-1982.  While  the  ISO  and 
ANSIdEEE  Pascal  standards  are  compatible,  there  are  some  differences  in  technical  substance  as 
well  as  some  errors  in  the  ISO  standard. 

In  January  1985  the  US  Federal  Government  adopted  the  ANSI/IEEE  standard  as 
FIPS  109.  The  implementation  of  FIPS  Pascal  involves  three  areas  of  consideration: 

•  Acquisition  of  Pascal  processors 

•  Interpretation  of  FIPS  Pascal 

•  Validation  of  Pascal  processors. 

On  10  April  1990,  ANSI  X3  and  the  IEEE  approved  the  Extended  Programming  Language 
Pascal  standard  as  IEEE  770  and  ANSI  X3.160.  This  was  adopted  in  1991  by  ISO  as 
ISO  10206. 

4.2.3  C  Programming  Language 

C  originated  in  the  late  1970s  as  the  programming  language  of  the  UNIX17  operating 
system.  It  is  a  general-purpose  programming  language  that  features  economy  of  expression, 
modem  flow  control  and  data  structures,  and  a  rich  set  of  operators. 

C  is  not  a  very  "high  level"  language,  nor  a  complex  one.  Its  particular  area  of  application 
is  systems  programming  (e.g.,  software  for  an  operating  system).  Although  it  was  originally 
implemented  on  a  DEC  PDP-1 1,  it  is  now  widely  used.  [Ref.  Kemighan  1988] 

Its  growing  popularity,  changes  in  the  language  over  the  years,  and  the  creation  of 
compilers  by  groups  not  involved  in  its  design  raised  the  need  for  a  standard  in  the  early  1980s. 


17  UNIX  is  a  registered  trademark  of  Unix  System  Laboratories,  a  wholly  owned  subsidiary  of  Novell,  Inc. 
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[Ref.  Kemighan  1988]  In  1989,  ANSI  promulgated  X3.1S9,  Programming  Language  C.  In 
1990,  this  standard  was  adopted  by  ISO  (ISO  9899).  It  was  also  recently  approved  by  the  US 
Federal  Government  as  FEPS- 160. 

There  is  an  ASC  X3  project  (0743-D)  to  promulgate  a  standard  for  Programming  Language 
C++,  a  higher-level  update  of  C.  There  is  no  draft  standard  yet,  but  estimated  completion  is  1994. 
According  to  a  recent  study  by  UNIX  tool  supplier  Lucid  [Ref.  OSN  1993j],  businesses  are 
moving  from  C  to  C++  faster  than  expected  with  80  percent  of  the  market  either  using  or  in 
transition  to  C++. 

Technical  Committee  ANSI  X3J1 1  of  ASC  X3  is  developing  a  technical  report  (TR)  for 
numerical  C  extensions.  The  objective  of  the  report  is  to  outline  the  technical  issues  involved  in 
adding  more  support  for  numerical  programming  in  Programming  Language  C.  The  issues  that 
have  been  identified  are  [Ref.  X3  1991h]: 

•  Optimization  of  potentially  aliased  variables 

•  Support  for  vector  hardware 

•  Complex  arithmetic 

•  Variability  dimensioned  arrays 

•  IEEE  issues  including  infinity 

•  Exception  handling 

•  Support  for  parallel  processing 

•  Syntax  for  array/matrix  operations. 

To  date,  three  subgroups  have  completed  their  work,  resulting  in  the  publication  of  Parts  1-3  of  the 
report  for  comment.  The  parts  are: 

•  Parti:  Designated  Initializers  and  Compound  Literals 

•  Part  2:  Aliasing  Control  via  Restricted  Pointers 

•  Part  3:  Floating-Point  C  Extensions. 

ANSI  X3  recently  announced  the  approval  of  a  new  project  for  Programming  Language  C 
Information  Bulletins  under  the  auspices  of  ANSI  X3J1 1.  ANSI  X3J1 1  has  compiled  numerous 
requests  for  interpretation  or  clarification  of  ANSI  X3. 159- 1989,  and  the  bulletin  will  provide  a 
means  of  making  those  interpretations  available  to  the  public.  [Ref.  X3  1991m] 

4.2.4  COBOL  Programming  Language 

COBOL  programming  language,  which  is  primarily  used  for  business  applications,  is  an 
ANSI  (X3.23-1985)  standard  that  was  also  adopted  in  1985  by  ISO  (ISO  1989).  It  was  adopted 
by  the  United  States  in  1986  as  FIPS  21-2.  ISO  1989  has  one  amendment.  Intrinsic  Function 
Module ,  1992. 

ANSI  X3J4  is  developing  a  revision  of  standard  COBOL  that  is  scheduled  to  be  available 
for  public  review  in  1995  or  1996.  This  revision  will  be  an  upward  compatible  enhancement  of 
two  existing  COBOL  standards: 

•  X3.23-1985[R1991  ],  Programming  Language  COBOL 

•  X3.23a- 1 989[R  1991],  Intrinsic  Function  Module  for  COBOL  (ISO  1989  AM  1). 

Other  work  undertaken  by  X3J4  includes  interpretation  of  the  existing  COBOL  standard 

and  development  of  three  addenda:  (1)  Correction  of  Errors  and  Resolution  of  Ambiguities, 
(2)  Support  for  Multi-Octet  Character  Sets,  and  (3)  a  native  language  binding  for  the  Forms 
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Interface  Management  System  (FIMS)  being  standardized  (see  Section  5.2.9)  by  the  Conference 
on  Data  Systems  Languages  (CODAS YL)  FIMS  Committee.  [Ref.  X3  1992g] 

In  October  1992,  ANSI  X3  announced  the  formation  of  a  new  task  group,  X3J4.1,  object- 
oriented  COBOL.  The  task  group  will  be  responsible  for  producing  a  technical  report  for  the 
purpose  of  submitting  potential  object-oriented  extensions  for  review  and  comment  before  they  are 
incorporated  into  the  next  revision  of  COBOL  standard  X3.23-1985.  X3j4.1  will  continue  the 
work  of  the  object-oriented  COBOL  Task  Group  formed  in  1989  by  the  CODASYL  COBOL 
Committee.  [Ref.  X3  1992i]  The  current  standard  does  not  include  real-time,  operating  system,  or 
communications  components,  although  this  may  change  with  the  functionality  introduced  by 
proposed  revisions  [Ref.  APP  1992]. 

4.2.5  FORTRAN  Programming  Language 

In  1978,  ANSI  promulgated  a  standard  for  FORTRAN  (ANSI  X3.9),  a  programming 
language  for  scientific  numerical  computation  that  has  wide  use  and  many  variations.  In  1980,  this 
standard  was  endorsed  by  ISO  (ISO  1539)  and  is  now  in  Edition  2  (ISO  1539:1991).  FIPS  69 
adopted  X3.9-1978  in  September  1980  as  a  US  standard  to  promote  portability  of  FORTRAN 
programs  for  use  on  a  variety  of  data  processing  systems.  The  most  recent  FIPS  (FIPS  69-1)  was 
issued  in  December  1985;  a  revised  ANSI  standard  was  issued  in  1989.  An  ANSI  X3J3  project 
X3.198  produced  an  extended  version  of  FORTRAN  ( Programming  Language  FORTRAN  90 )  in 
1992.  Non-standard  versions  of  FORTRAN  exist,  posing  potential  interoperability  problems. 

4.2.6  LISP  and  Prolog  Programming  Languages 

LISP  is  currently  the  most  popular  computer  language  used  in  artificial  intelligence  (AI) 
programming  in  the  United  States,  although  Prolog  standardization  efforts  arc  underway  in  the 
United  Kingdom.  LISP  is  designed  for  supporting  symbolic  manipulation  and  the  interactive, 
trial-and-error  style  of  programming  employed  by  many  AI  researchers.  It  was  invented  in  1958 
and  has  many  dialects.  The  dialects  tend  to  fall  into  two  main  camps:  INTERLISP  and 
MACLISP.  In  the  interest  of  standardization,  Common  LISP  was  developed.  [Ref.  Steele  1984] 
It  is  not  yet  an  official  standard,  but  was  created  at  the  initiative  of  many  vendors  and  is 
increasingly  becoming  the  preferred  version.  Common  LISP  compilers  exist  for  several 
mainframe  computers  [Ref.  Schutzer  1987],  minicomputers,  and  microcomputers.  The  Standards 
Committee  ANSI  X3J13  is  working  on  an  ANSI  standard  for  Common  LISP  (X3.226, 
Programming  Language  Common  LISP ,  draft). 

Except  for  efforts  to  standardize  Scheme  (IEEE  1 178,  which  was  approved  in  December 
1990)  and  the  AI  programming  language  Prolog,  there  are  currently  no  other  standards  for 
knowledge-based  specifications  or  notations.  (Knowledge-based  systems  are  discussed  in 
Section  4.3.3,  and  knowledge  engineering  is  discussed  with  distributed  system  services  in 
Section  13.5.3.) 

4.2.7  BASIC  Programming  Language 

BASIC  is  distinguished  from  other  programming  languages  in  its  concern  for  the 
unsophisticated  or  novice  user.  While  BASIC  is  a  general-purpose  programming  language,  it  is 
designed  primarily  to  be  easy  to  learn,  easy  to  use,  and  easy  to  remember.  It  is  oriented  toward, 
but  not  restricted  to,  interactive  use.  Its  constructions  are  kept  simple  and  special  rules  are  kept  to  a 
minimum.  The  ANSI  standard  for  Minimal  BASIC  (X3.60)  was  promulgated  by  ANSI  in  1978 
and  adopted  as  FIPS  68  in  1980.  It  was  subsequently  adopted  by  ISO  in  1984  (ISO. 6373).  In 
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1987,  ANSI  withdrew  X3.60-1978  and  superseded  it  with  a  standard  for  Full  BASIC  (X3.113- 
1987),  which  was  adopted  as  FIPS  68-2  in  August  1987  and  by  ISO  in  1991  (ISO  10279).  This 
revision  reflects  major  changes,  improvements,  and  additions  to  the  BASIC  specification.  In 
December  1989  ANSI  issued  the  standard  ANSI  X3. 1 13  A,  Addendum  to  Programming  Language 
Full  BASIC,  Modules,  and  Individual  Character  Input. 

4.2.8  Fourth  Generation  Languages  (4GLs) 

Historically,  there  have  not  been  any  standards  for  fourth  generation  languages.  One  effort 
to  address  this  deficiency  is  the  work  of  ANSI  X3J19,  Xbase.  Xbase  is  an  application 
development  language  derived  from  Jet  Propulsion  Data  Management  and  Information  Center,  a 
mainframe-based  package.  The  first  broadly  successful  product  based  on  Xbase  was  dBase  II  in 
1981.  Currently  available  products  using  the  Xbase  language  include  dBase  IV,  dBase  III  Plus, 
Fox  Base  Plus,  Fox  Pro,  dBFast,  Clipper,  Arago  Quicksilver,  Arago  dBXL,  Force  Recital, 
Vulcan,  and  qBase.  Xbase  products  are  currently  available  for  DOS,  UNIX,  Windows,18  OS/2, 
VMS,  Ultrix,  and  Solaris.  [Ref.  X3  1992e]  The  basic  standard  was  expected  to  be  on  the  street 
for  worldwide  coordination  by  the  fall  of  1993. 

4.3  Standards  for  Software  Environments 

4.3.1  Bindings 

In  addition  to  programming  language  standards,  several  standards  provide  interfaces  or 
connectivity  between  programming  languages  and  applications.  Such  "landings"  exist  or  are  being 
proposed  for  such  standards  as  POSEX  (IEEE  P1003),  Graphical  Kernel  System  (GKS, 
ISO  7942),  three-dimensional  GKS  (GKS-3D,  ISO  8805),  Programmer’s  Hierarchical  Interactive 
Graphics  System  (PHIGS,  ISO  9592  and  9593),  Information  Resource  Dictionary  System  (IRDS, 
10728),  and  Computer  Graphics  Interface  (CGI,  ISO  9636  and  9638). 

POSIX  bindings  are  now  being  developed  only  for  Ada  and  FORTRAN.  IEEE  1003.5, 
Ada  Bindings  for  POSIX,  and  IEEE  1003.9,  FORTRAN  Bindings  far  POSIX,  were  approved  in 
June  1992.  IEEE  work  on  a  C  binding  for  POSIX  and  FORTRAN  90  language  bindings  has 
been  withdrawn.  Woik  on  Ada  real-time  bindings  is  now  in  P1003.5b  (formerly  PI 003.20). 

ANSI  and  ISO  have  approved  standards  for  FORTRAN,  Pascal,  Ada,  and  C  bindings  for 
GKS.  They  are: 

•  ISO  8651-1  (Part  1):  FORTRAN  Binding  (ANSI  X3. 124. 1-1985),  1988 

•  ISO  8651-2  (Part  2):  Pascal  Binding  (ANSI  X3. 124.2- 1985),  1988 

•  ISO  8651-3  (Part  3):  Ada  Binding  (ANSI  X3. 124.3- 1985),  1988 

•  ISQ/IEC  8651-4  (Part  4):  C  Binding  (ANSI  X3. 124.4- 1991),  1991. 

ISO  standards  are  being  developed  for  GKS-3D  bindings  for  FORTRAN  and  Ada.  The  C 
binding  has  reached  IS  status.  Pascal  and  LISP  bindings  are  under  development  They  are: 

•  DIS  8806-1  (Part  1):  FORTRAN  Binding,  1988 

•  DIS  8806-3  (Part  3):  Ada  Binding,  1989 

•  ISQ/IEC  8806-4  (Part  4):  C  Binding,  1991 


18  X- Window  System  (commonly  referenced  as  X- Windows)  is  a  trademark  of  the  Massachusetts  Institute  of 
Technology.  Windows  is  a  registered  trademark  of  Microsoft  Corporation. 
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•  Pascal  Binding  [SC24  N  190]  (ANSI  Project 0545-1) 

•  USP  Binding  (ANSI  Project  X3. 122.5-  199x). 

There  are  ISO  standards  for  Ada,  FORTRAN,  and  C  bindings  to  PHIGS.  The  Pascal 
binding  is  awaiting  balloting.  The  standards  are: 

•  ISO/IEC  9593-1  (Part  1):  FORTRAN  Binding  (ANSI  X3.144.1-199x),  1990 
«  DIS  9593-2  (Part  2):  Pascal  Binding  (ANSI  X3. 144.2-  199x) 

•  ISO/IEC  9593-3  (Part  3):  Ada  Binding  (ANSI  X3.144.3-199x),  1990 

•  ISO/IEC  9593-4  (Part  4):  C  Binding  (ANSI  X3.144.4- 1992),  1992. 

The  FORTRAN,  Pascal,  Ada  and  C  bindings  to  CGI  are: 

•  ISO  9636,  Computer  Graphics  -  Interfacing  (CGI)  Techniques  for  Dialogues  with 
Graphical  Devices  -  Functional  Specification 

-  WD  9636-8  (Part  8):  FORTRAN  Language  Binding  of  CGI,  1989 
WD  9636-1 1  (Part  1 1):  C  Language  Binding  of  CGI,  1989 

•  ISO  9638,  CGI  Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI 
Language  Bindings 

-  DIS  9638-1  (Part  1):  FORTRAN 

-  DIS  9638-2  (Part  2):  Pascal 

-  DIS  9638-3  (Part  3):  Ada 

-  DIS  9638-4  (Part  4):  C. 

IRDS  bindings  are  as  follows: 

•  ISO  10728/PD  AM  1,  C  Language  Binding,  1993 

•  ISO  10728/WDAM  2,  Ada  Language  Binding,  1993. 

Specification  for  a  Set  of  Common  Language-Independent  Data  Types  (CUD) 
[ISO  11404]  defines  specific  common  language-independent  data  types  by  the  following  [Ref. 
X3  1991n]: 

•  Identifying  distinct  data  types  by  their  characteristics,  functions,  values,  value- 
relationships,  etc. 

•  Assigning  identifiers,  or  formal  reference  syntax,  to  each  distinguished  data  type 

•  Defining  a  means  by  which  users  or  related  standards  may  define  additional  data  types 

•  Defining  the  form  of  and  requirements  for  mappings  between  the  data  types  of  a 
programming  or  specification  language  and  the  language-independent  data  types 
defined  by  the  standard. 

ISO/IEC  JTC 1/SC22/WG 1 1  on  Binding  Techniques  for  Languages  has  several  projects 
underway,  some  of  which  are  broader  in  scope  than  the  name  of  the  WG  suggests.  The  following 
work  items  have  been  assigned  to  SC22/WG1 1  [Ref.  SC 21  N  5682  1991]: 

•  DTR  10182,  Binding  Techniques  for  Programming  Languages,  February  1992.  The 
scope  of  this  technical  report  is  to  classify  language  binding  methods,  report  on 
particular  instances  in  detail,  and  produce  suggested  guidelines  for  future  language 
binding  standards. 

•  Specification  for  a  Model  for  Common  Language-Independent  Procedure  Calling 
Mechanisms  (CUPCM  or  CUP)  [SC22/WG22  N  194R].  This  project  intends  to 
specify  a  generic  way  for  referencing  procedures.  A  draft  was  circulated  among  SC22 
member  bodies  for  registration  as  a  CD  document  in  February  1991. 

•  CD  10967-1,  Language  Compatible  Arithmetic  -  Part  1:  Integer  and  Floating  Point 
Arithmetic.  The  focus  of  this  standard  is  on  the  portability  of  single  language 
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programs  across  diverse  platforms.  Part  2  will  deal  with  complex  arithmetic  and 
mathematical  procedures.  [Ref.  X3  1992k] 

Bindings  for  fourth  generation  languages  (4GLs),  however,  have  yet  to  be  standardized. 
This  could  pose  a  problem  if  4GLs  were  used  for  database  queries. 

Other  Ada  binding  standards  include  the  following: 

•  Generic  Package  of  Elementary  Functions  (GPEF) — currently  being  formatted  as  a 
draft  international  standard.  Ada,  unlike  other  languages,  does  not  include  built-in  or 
predefined  elementary  functions  such  as  SQRT,  SIN,  and  EXP.  The  proposed 
standard  will  specify  20  mathematical  functions. 

•  Generic  Package  of  Primitive  Functions  (GPPF) — accepted  for  voting  by  Numerics 
Rapporteur  Group.  It  is  intended  to  provide  primitive  operation  required  to  endow 
mathematical  software,  such  as  implementations  of  the  elementary  functions,  with  the 
qualities  of  accuracy,  efficiency,  and  portability.  The  package  contains  primitive 
functions  and  procedures  for  manipulating  the  fraction  part  and  the  exponent  part  of 
machine  numbers  of  the  generic  floating-point  type.  Additional  functions  are  provided 
for  directed  rounding  to  a  nearby  integer,  for  computing  an  exact  remainder,  for 
transferring  the  sign  from  one  floating  point  machine  number  to  another,  and  for 
shortening  a  floating  point  machine  number  to  a  specified  number  of  leading  radix 
digits. 

Bindings  for  the  following  are  described  elsewhere  in  this  document:  SQL  (Section  6.2.2.2); 
Transmission  Control  Protocol  (TCPyintemet  Protocol  (IP),  (Section  9.7.4);  X-Windows 
(Section  5.2.5),  Motif19  (Section  5.2.7),  and  OPEN  LOOK20  (Section  5.2.8). 

4.3.2  Software  Engineering  Environments  (SEE) 

A  software  engineering  environment  consists  of  a  set  of  tools  cooperating  harmoniously 
together  to  support  specific  processes  through  interoperability,  sharing  of  data  (via  a  uniform  data 
repository),  and  presentation  style.  [Ref.  Yeh  1992]  Five  SEE  specifications  are  discussed  in  the 
paragraphs  below:  NIST/ECMA  Reference  Model,  Portable  Common  Tool  Environment  (PCTE), 
integrated  computer-aided  software  engineering  (ICASE),  Manufacturing  Automation 
Programming  Language  Architecture  (MAPLE),  and  Next  Generation  Computer  Resources 
(NGCR). 

4.3.2. 1  NIST/ECMA  Reference  Model 

ECMA  and  NIST  have  jointly  produced  a  Reference  Model  for  Frameworks  on  Computer 
Assisted  Software  Engineering  Environments,  Third  Edition,  August  1993  (ECMA  Technical 
Report  55;  NIST  SP  500-211).  ECMA  TC33  Technical  Group  on  Reference  Models  (TGRM) 
initially  developed  the  framework,  which  the  NIST  Integrated  Software  Engineering  Environment 
(ISEE)  Working  Group  adopted,  enhanced,  and  extended  to  support  NIST  goals.  The 
NIST/ECMA  Frameworks  Reference  Model  defines  many  services,  grouping  them  into  object 
management,  process  management,  communication,  operating  system,  user  interface,  policy 
enforcement,  and  framework  administration. 

NIST  is  also  working  to  establish  a  Federation  of  Integrated  SEE  Laboratories  (FEDISEE). 
FEDISEE  goals  would  be  (1)  to  act  as  a  technology  exploitation  and  transfer  mechanism  for 
distributed  computing  and  distributed  repositories  and  (2)  to  develop  a  distributed  development 


19  OSF/Motif  is  a  trademark  of  the  Open  Software  Foundation,  Inc. 

20  OPEN  LOOK  is  a  trademark  of  Unix  System  Laboratories,  a  wholly  owned  subsidiary  of  Novell,  Inc. 
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environment  The  NIST  ISEE  Laboratory  would  serve  as  the  focal  and  coordination  point  The 
Federated  environment  would  be  a  coalition  of  distinct,  individual  software  engineering 
environments  that  can  function  together  or  independently.  Users  will  have  the  perspective  of  a 
single  system  image  of  a  distributed  environment  and  repository.  [Ref.  Martin  1992]  (Distributed 
computing  is  discussed  in  Chapter  13.) 

4. 3. 2. 2  Portable  Common  Tool  Environment  (PCTE) 

Another  software  engineering  environment  standardization  project  is  the  PCTE 
(DIS  13719).  Other  projects  standardize  the  interfaces  between  tools  that  might  be  combined  to 
create  an  environment  Of  particular  interest  are  CASE  tools  (see  Section  4.3.2.3  below). 

PCTE  Development  and  Standards.  The  PCTE  project  was  begun  in  1983  by  the 
Commission  of  the  European  Communities  (CEC)  European  Strategic  Programme  for  Research  in 
Information  Technology  (ESPRIT).  ECMA  Technical  Committee  33  developed  and  standardized 
the  ECMA  PCTE  Abstract  Specification  (ECMA- 149)  in  December  1990.  [Ref.  Davis  1990]  The 
C  Programming  Language  Binding  to  PCTE  (ECMA- 158)  was  approved  in  June  1991.  An  Ada 
Programming  Language  Binding  (ECMA- 162)  was  completed  in  December  1991.  A  C++  binding 
is  expected  in  June  1994.  [Ref.  Davis  1992]  Second  editions  of  the  Basic  ECMA  Standards  for 
PCTE  (ECMA- 149,  ECMA-159,  and  ECMA-162)  are  ready  to  be  submitted  for  ISO 
standardization.  At  its  plenary  in  June  1993,  SC 21  resolved  to  propose  PCTE  as  a  fast  track  DIS 
(DIS  13719).  [Ref.  SC21  N  8081  1993]  DIS  13719  is  a  three-part  standard  that  includes  ECMA- 
149,  ECMA-158,  and  ECMA  162. 

The  goal  of  the  PCTE  project  was  to  describe  and  prototype  tool  interfaces  that  could  be 
used  to  define  a  software  development  environment.  The  environment  would  comprise  a  set  of 
public  tool  interfaces  (PITs)  as  well  as  a  data  management  system.  As  defined  by  the  PCTE 
project,  a  PIT  is  a  non-proprietary  interface  existing  as  a  library  unit  that  may  be  used  by  a  tool  to 
provide  access  to  system  services.  Tool  builders  might  use  the  interfaces  to  either  integrate  or 
attach  their  tool  products  to  an  environment  The  distinction  between  integration  and  attachment 
reflects  die  degree  to  which  the  environment  monitors,  controls,  and  makes  use  of  the  information 
on  a  given  tool.  An  integrated  tool  makes  full  use  of  the  services  provided  by  the  environment 
such  as  logging  an  audit  trail  and  data  management  An  attached  tool  does  not  for  example,  data 
are  maintained  in  a  repository  known  only  to  that  tool 

The  criteria  for  development  of  the  PCTE  were  that  it  be  policy  and  mechanism 
independent  support  a  distributed  environment  provide  easy  tool  integration,  provide  a  complete 
interface  definition,  and  provide  multi-language  support  To  accomplish  this,  PCTE  defines  the 
services  needed  by  the  tools.  The  services  provided  by  PCTE  include  data  management  tool 
execution  and  communication,  distribution  and  environment  management  and  programmer 
interface  for  user  interface  management 

Convergence  with  CAIS-A.  The  Portable  Common  Tools  Interface  Set  (PCIS) 
project  was  created  to  resolve  the  unsatisfactory  situation  that  had  arisen  in  the  late  1980s,  that  the 
independent  efforts  of  Europe  and  the  United  States  to  produce  a  PTI  had  resulted  in  two 
contenders  for  an  international  standard,  PCTE  and  CAIS-A  (see  Section  4.2.1.2).  In  an  attempt 
to  discover  a  convergence  path,  a  study  was  carried  out  in  1988  and  1989,  jointly  on  behalf  of  the 
Independent  European  Programming  Group  Technical  Area  13  (IEPG-TA13)  and  die  AJPO.  This 
study  concluded  that  it  would  be  feasible  to  make  a  union  of  the  two  PTIs  and  in  August  1989  the 
AJPO  and  IEPG  agreed  to  pursue  the  convergence  path.  The  name  "PCIS"  was  coined  by 
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appropriately  "converging  "  the  acronyms  PCTE  and  CAIS-A.  PCIS  later  agreed,  however,  to 
abandon  the  path  of  convergence  and  has  based  its  framework  definition  upon  PCTE,  virtually  to 
the  exclusion  of  CAIS-A.  PCIS  may  therefore  be  regarded  as  a  set  of  proposals  for  enhanc^Hwnft 
to  PCTE  [Ref.  Boyer  1993] 

Organisations  Promoting  PCTE  The  PCTE  Interface  Management  Board  (PIMB) 
Association  (see  Appendix  F)  is  a  non-profit  international  company  whose  purpose  is  to  promote 
greater  use  of  the  PCTE  interface  and  to  encourage  development  of  tools  and  software  engineering 
methodologies  using  PCTE.  [Ref.  Vemocchi  1992] 

The  North  American  PCTE  Initiative  (NAPI)  was  formed  in  October  1992  by  the  US  DoD, 
NIST,  and  Object  Management  Group  to  increase  the  visibility  and  use  of  PCTE  and  to  accelerate 
the  evolution  of  PCTE  and  its  adoption  as  a  standard.  [Ref.  Davis  1992]  The  first  NAPI  meeting 
was  held  November  1992  at  NIST.  [Ref.  NAPI  1992] 

Relation  rtf  PCTE  and  IRDS.  Noting  a  major  overtap  between  PCTE  and  ISO  10728, 
IRDS  Services  Interface,  SC21  is  recommending  the  following  fast-track  procedure  [Ref. 
SC21  N  8103  Revised  1993]: 

•  Circulate  die  PCTE  document  for  review  by  JTC1  national  bodies 

•  Call  a  joint  meeting  of  the  concerned  subcommittees  with  ECMA  to  allow  discussion 
of  appropriate  action  in  relation  to  the  overlap. 

One  option  to  address  the  overlap  is  to  incorporate  those  PCTE  functionalities  not  in 
ISO  10728  into  future  IRDS  versions  [EWOS  1991a].  One  comment  from  a  PCTE  supplier  (EDS 
SC3CON)  noted  that  PCTE  provides  a  rich  set  of  security  facilities,  mandatory  and  discretionary, 
that  have  no  parallel  in  IRDS,  making  IRDS  unsuitable  (in  their  view)  for  safety-critical  systems  or 
secure  systems. 

In  December  1993,  the  UK  Government  Centre  for  Information  Systems.  Central 
Computer  and  Telecommunications  Agency  (CCTA)  completed  a  thorough  review  of  this  overlap. 
This  comparison  noted  the  following  differences  [Ref.  DISC  1993b]: 

•  Services  in  ISO  10728  for  which  there  are  no  PCTE  equivalents: 

Information  Resource  Domain  (IRD)  creation  and  removal  (the  equivalent 
functionality  is  outside  the  scope  of  the  PCTE  DIS) 

Operand  Close  IRDS  (the  equivalent  functionality  is  outside  the  scope  of  the 

Creation  and  manipulation  of  reference  paths  between  working  sets 
Two-phase  commit 

Get  Diagnostics,  which  provides  detailed  information  about  an  error  code 
Open  Cursor  (specifying  a  query  expression),  Retrieve  Object  using  a  cursor,  mid 
Close  Cursor 

Declassify  Object  (PCTE  provides  an  equivalent  to  Reclassify,  to  make  an  object 
more  tightly  typed,  but  not  the  converse) 

Change  of  Working  Set  Content  Status  to  uncontrolled  (updateable),  controlled 
(frozen),  or  archived. 

•  Facilities  found  in  the  new  extensions  to  IRDS  for  which  there  are  no  equivalents  in 
ISO  10728  or  in  PCTE: 

Registration  of  operations,  methods  (in  an  object-oriented  programming  sense), 
and  their  parameters 
Invocation  of  operations. 
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•  PCTE  services  not  provided  by  ISO  10728  or  its  extensions: 

Process  Management  Services,  including  pipes,  Hies,  a  notification  service,  and 
message  queues 

Nested  commit  and  rollback,  which  allows  a  controlling  activity  to  abort  the  work 
of  one  of  its  subactivities  even  after  die  subactivity  has  gone  “commit" 
Maintenance  of  replicas  of  objects  on  replica  volumes 

Operations  to  connect  workstations  to  the  PCTE  installation  and  later  disconnect 
them,  along  with  miscellaneous  file  copy  and  time  functions. 

The  report  noted  that  it  would  be  possible  to  provide  a  PCTE  object  management  set  of 
services  implemented  on  top  of  the  ISO  IRDS  Services  Interface  and  that  it  would  be  possible  to  do 
the  reverse  as  well.  However,  the  report  suggested  it  would  be  more  likely  that  implementors  will 
provide  both  interfaces  to  the  same  underlying  database.  Suggestions  included  in  the  report  could 
serve  to  improve  the  compatibility  between  the  standards,  making  the  two  object  management 
systems  more  similar  and  hence  easier  for  a  vendor  to  provide  both  interfaces  to  the  same 
underlying  repository.  Additional  comments  contained  in  the  report  including  the  following  [Ref. 
CCTA 1993]: 

•  Improving  compatibility  might  be  the  best  way  forward  for  the  user  community,  who 
would  like  their  CASE  tools  to  interoperate,  whatever  standard  the  CASE  tool  vendor 
chooses  to  use.  A  greater  degree  of  compatibility  would  make  it  easier  for  vendors  to 
offer  one  product,  storing  its  information  in  one  database,  and  supporting  both 
interfaces. 

•  It  is  likely  that  large  sites  will  end  up  not  only  with  both  IRDS  and  PCTE  products  but 
also  with  products  using  other,  de  facto  repository  standards  and  with  products  using 
proprietary  repositories.  Interoperability  will  become  a  major  issue  for  such  sites.  It 
may  therefore  be  important  for  both  IRDS  and  PCTE  developers  to  work  in  wider 
communities  on  the  general  problem  of  interoperability,  for  example,  on  common 
object  models  and  abstract  schemas  that  can  be  mapped  to  both  IRDS  content  modules 
and  PCTE  Schema  Definition  Sets. 

4. 3. 2. 3  ICASE 

IEEE  1209,  Recommended  Practice  for  Evaluating  CASE  Tools  was  approved  in  1992. 
The  Institution  of  Electrical  Engineers  (IEE)/British  Computer  Society  Joint  Working  Party  on 
Software  Engineering  Standards  has  also  discussed  the  possibility  of  investigating  CASE  tools 
and,  in  particular,  the  way  in  which  their  use  supports  conformance  to  high  quality  standards. 
However,  the  only  planned  activity  was  to  comment  on  IEEE  P1209.  In  discussions  related  to  a 
proposed  UK  MOD  standard  (DEF-STAN-00-55),  Requirements  for  the  Procurement  of  Safety 
Critical  Software,  the  remark  has  been  made  that  currently  available  CASE  tools  would  not  meet 
their  requirements,  since  none  of  the  tools  has  been  or  can  be  subject  to  the  kind  of  formal  methods 
analysis  laid  down  in  the  proposal  [Ref.  Kemp  1990]. 

Another  issue  with  respect  to  tools  and  toolsets  is  the  ability  to  interconnect  tools  from 
different  software  developers.  Consequently,  the  IEEE  Computer  Society  approved  a  project 
authorization  request  (PAR)  for  a  Standard  Reference  Model  for  Computing  System  Engineering 
Tool  Interconnections  (PI  173)  in  February  1988.  The  core  of  this  standard  is  the  Standard  Text 
Language  (STL),  which  describes  concepts  such  as  data,  conditions,  events,  and  states,  as  well  as 
transformation,  control-transition,  and  state-transition  operations.  The  standard  supports  both 
textual  and  graphical  forms.  [Ref.  PI  173  1989]  It  was  approved  in  1991  and  a  PAR  for  its 
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revision  was  approved  October  1993.  ANSI  X3H6  on  CASE  Tool  Integration  Models  (CTlM) 
was  recently  formed. 

The  CASE  Integration  Services  (CIS)  Committee  is  also  trying  to  provide  direction  for 
integration  standards  in  the  CASE  arena.  Originally  formed  to  discuss  a  standard  interface  for 
services  to  assist  in  the  integration  of  software  engineering  tools  into  CASE  environments,  the  CIS 
committee  is  now  a  public  forum  with  many  organizations  participating  in  its  deliberations  and 
others  monitoring  the  process  as  observers.  The  CIS  committee  has  chosen  to  focus  on  two  areas: 
(1)  data  integration,  the  sharing  of  meta-data  among  tools,  and,  (2)  control  integration,  the  sharing 
of  control  information  among  tools. 

A  standard  known  as  ATIS  (Atherton  Tools  Integration  Services,  or  alternatively,  A  Tools 
Integration  Standard)  [Ref.  CIS  1990],  which  was  developed  jointly  by  Digital  Equipment 
Corporation  and  Atherton  Technology,  was  proposed  as  a  Base  Document  for  the  CIS  work  and  is 
under  review  by  committee  members.  ATIS  is  based  on  the  object-oriented  interfaces  in  Atherton 
Technology's  Software  BackPlane  product  While  it  addresses  many  of  the  integration  issues,  it 
does  so  as  a  monolithic  solution  and  has  several  deficiencies.  However,  the  general  solution 
offered  by  ATIS,  (i.e.,  an  object-oriented  approach  based  on  defined  and  extensible  schema  and 
methods)  is  considered  by  CIS  members  to  be  the  preferred  approach  to  providing  integration 
services.  Thus  ATIS  can  provide  a  starting  point  for  the  ongoing  work  of  CIS.  [Ref.  Nolan  1990] 
At  CIS's  request  ANSI  is  considering  making  CIS  a  group  to  pursue  this  standards  issue. 

Another  standardization  activity  in  this  area  is  the  CASE  Data  Interchange  Format  (CDIF) 
effort  The  CDIF  Technical  Committee  operates  under  the  authority  of  the  Electronic  Industries 
Association  (EIA),  and  its  charter  is  "to  develop  an  ANSI  standard  (eventually  to  become  an  ISO 
standard)  for  the  exchange  of  information  between  CASEs."  Three  releases  of  standards  are 
planned:  a  framework  standard,  a  syntax  standard,  and  a  semantic  standard.  Their  EIA  Project 
Numbers  (PNs)  are  2387, 2389,  and  2329,  respectively.  [Ref.  Ornstem  1991]  These  standards 
are  currently  in  interim  form  with  plans  to  re-issue  them  early  in  1994.  [Ref.  Boyer  1993]  Both 
Continuous  Acquisition  and  Life  Cycle  Support  (CALS,  formerly  Computer  Acquisition  and 
Logistics  Support)  and  PI  175  representatives  have  participated  in  the  meetings. 

ANSI  X3  has  begun  a  development  project  for  IRDS  Extensions  to  Support  CASE 
Environment  for  Information  Interchange.  This  standard  would  define  an  IRDS,  based  on  ANSI 
X3.138-1988,  capable  of  supporting  the  full  range  of  IRDS  applications.  In  particular,  it  would  be 
capable  of  acting  as  the  IRD  in  a  traditional  data  processing  environment  and  capable  of  providing 
the  stable  store  necessary  to  support  an  ICASE  environment.  The  standard  would  include  both  die 
semantics  of  the  IRDS  and  a  software  interface  suitable  to  the  needs  of  active  CASE  and  Dictionary 
tools.  The  development  has  been  assigned  to  Technical  Committee  ANSI  X3H4.2.  [Ref.  X3 
1990] 

4. 3. 2. 4  MAPLE 

Work  on  a  programming  language  environment  architecture  by  ISO  TC194/SC5  has 
resulted  in  ISQ/TR  1286,  Manufacturing  Automation  Programming  Language  Environment 
Architecture  (MAPLE),  1993.  The  project  specifies  the  components  of  MAPLE  (services  and 
libraries),  the  interrelation  between  these  components  and  the  development  of  functional 
specifications  for  the  components.  It  does  not  cover  the  implementation  of  the  components. 
Adherence  to  the  architecture  is  expected  to  reduce  programming  time,  increase  program  quality, 
and  reduce  cost  of  integration.  [Ref.  SC21/WG3  N  1371  1992] 
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4. 3. 2. 5  NGCR 

Another  environment  reference  model  project  is  the  US  Navy  Next  Generation  Computer 
Resources  (NGCR)  Project  The  program  revolves  around  the  selection  of  interface  standards  in 
six  areas.  The  interface  standards  will  be  based  on  existing  industry  standards  with  multi-vendor 
support  The  objective  is  to  restructure  the  Navy's  approach  to  take  better  advantage  of  commercial 
advances  and  to  reduce  cost  and  duplication  of  computer  resources.  One  of  the  areas  chosen  by 
NGCR  for  interface  standardization  is  that  of  project  support  environments  (PSEs).  The  initial 
focus  for  the  PSE  Standards  Working  Group  (PSESWG)  is  to  identify  areas  in  support 
environments  that  are  in  need  of  standardization  and  for  which  industry  accepted  standards  may  be 
available  within  the  NGCR's  time  frame.  The  primary  goal  of  the  PSESWG  is  to  provide  an 
interface  standard  that  can  be  used  by  project  managers  as  an  aid  in  procuring  or  assembling  a 
PSE.  The  first  step  towards  this  goal  is  the  establishment  of  a  reference  model.  The  approach  taken 
in  the  NGCR  reference  model  is  most  directly  comparable  to  the  approach  evidenced  in  the  POSIX 
OSE  and  the  NIST/ECMA  Reference  Model.  The  intent  of  the  NGCR  Reference  Model  is  to 
encompass  the  domain  of  both  the  OSE  and  NIST/ECMA  domains.  The  approach  is  explicitly 
aimed  at  establishing  a  conceptual  basis  for  an  environment,  not  at  standardizing  any  particular 
environment  product  [Ref.  NGCR  1993] 

4.3.3  Knowledge-Based  Systems  (KBSs) 

Areas  where  standards  are  lacking,  probably  due  to  technological  immaturity,  include 
knowledge-based  systems  (KBSs)  and  software  repositories.  There  are  no  standards  for 
knowledge  exchange,  knowledge  management  or  development  of  knowledge  bases  for  life-cycle 
maintainability.  Several  standards  exist  or  are  under  development  in  the  areas  of  software  process 
models  and  development  methods. 

The  UK  General  Expert  System  Methods  Initiative  (GEMINI)  is  an  example  of  a  project 
that  is  addressing  needs  for  knowledge-based  standards.  In  mid- 1988,  the  CCTA  launched  this 
project  to  lay  the  foundation  for  a  systematic  KBS  development  methodology.  A  feasibility  study 
concluded  that  there  is  strong  support  for  such  a  method  and  that  its  development  is  both  timely 
and  feasible.  [Ref.  Montgomery  1989] 

On  March  1991,  the  IEEE  Standards  Board  approved  a  PAR  for  the  development  of  a 
Standard  for  an  Architecture  for  Knowledge  Representation.  The  IEEE  Project  number  is  P1252. 
[Ref.  P12S2  1991]  This  project  is  expected  to  address  issues  broader  than  KBS,  development 
methods,  and  tools. 

An  important  method  of  integrating  KBSs  is  by  means  of  the  IRDS  (ISO  10027).  The  first 
area  of  standardization  for  expert  systems  will  likely  be  bindings  between  expert  systems  and 
programming  languages,  databases,  and  user  interfaces.  Progress  towards  providing  decision 
support  and  decision  making  tools  and  methods  is  slow  but  may  be  stimulated  by  the  early  release 
of  the  IBM  Repository.  [Ref.  MODITSB  1989] 

4.3.4  Software  Repositories  and  Reuse 

Software  repository  standards  to  facilitate  software  reuse  do  not  yet  exist  These  might 
include  library  structure,  cataloging  scheme,  retrieval,  documentation  and  maintenance,  validation 
and  verification,  and  reuse  policy  and  guidance  standards.  Reuse  is  a  strategy  with  potential  to 
increase  software  productivity,  reliability,  and  quality.  A  1993  report  published  by  Ovum  finds 
that  while  repositories  and  frameworks  promise  many  benefits  for  systems  engineers,  products 
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available  at  present  are  poor.  Nearly  all  need  to  become  less  proprietary,  use  more  off-the-shelf 
tools,  and  be  enhanced  to  offer  wider  functionality.  [Ref.  OSN  1993k] 

4.3.5  Process  Models  and  Development  Methods 

A  model  of  the  software  development  process  is  the  ordered  sequence  of  activities  that 
occur  during  the  course  of  software  development.  Examples  of  software  development  process 
models  include  the  waterfall  model,  rapid  prototyping,  and  the  spiral  model.  By  contrast,  a 
software  development  method  (methodology)  is  the  way  the  specific  development  activities  are 
actually  carried  out  by  the  developer.  An  example  is  the  object-oriented  method. 

There  is  currently  a  single  US  standard,  DoD-STD-2167A  Defense  Software  Development 
Standard,  for  the  process  of  software  development  It  supersedes  DoD-STD-2167,  which  was  tied 
to  the  waterfall  model  and  did  not  easily  allow  tailoring  to  other  models.  ANSI  and  the  American 
Institute  for  Aeronautics  and  Astronautics  (AIAA)  recently  issued  a  related  standard.  Guide  for 
Implementing  Software  Development  Files  Conforming  to  DoD-STD-2167A  (ANSI/ AIAA  G-009- 
1991). 

The  DoD  is  revising  DoD-STD-2167A  and  harmonizing  it  with  DoD-STD-7935A  to 
develop  a  new  standard  called  MIL-STD-498  ( Software  Development  and  Documentation 
Standard).  Over  30  issues  are  being  addressed  during  this  harmonization  effort  one  of  which  is 
the  compatibility  of  DoD-STD-2167A  with  the  Ada  programming  language.  [Ref.  Singh  1992] 

The  IEEE  publishes  a  volume  of  Software  Engineering  Standards  [Ref.  IEEE  1983] 
comprising  17  standards  developed  for  software  engineering.  Most  of  the  standards  are  joint 
ANSI/IEEE  standards,  and  they  provide  recommendations  reflecting  the  state  of  the  art  in  the 
application  of  engineering  principles  to  the  development  and  maintenance  of  software.  The  17 
standards  are  the  following  (these  and  other  ANSI/IEEE  standards  are  listed  in  Appendix  H): 

1.  ANSI/IEEE  Std.  610.12  -  IEEE  Standard  Glossary  of  Software  Engineering 
Terminology,  1990 

2.  ANSI/IEEE  Std.  730  -  IEEE  Standard for  Software  Quality  Assurance  Plans,  1989 

3 .  ANSI/IEEE  Std.  828  -  IEEE  Standard  far  Software  Configuration  Management  Plans, 
1990 

4.  ANSI/IEEE  Std.  829  -  IEEE  Standard  for  Software  Test  Documentation,  1983 

5 .  ANSI/IEEE  Std.  830  -  IEEE  Guide  for  Software  Requirements  Specifications,  1984 

6.  IEEE  Std.  982.1  -  IEEE  Standard  Dictionary  of  Measures  to  Produce  Reliable 
Software,  1988 

7 .  IEEE  Std.  982.2  -  IEEE  Guide  for  the  Use  of  IEEE  Standard  Dictionary  of  Measures 
to  Produce  Reliable  Software,  1988 

8 .  ANSI/IEEE  Std.  983  -  IEEE  Guide  for  Software  Quality  Assurance  Planning,  1986 

9.  ANSI/IEEE  Std.  990  -  IEEE  Recommended  Practice  for  Ada  as  a  Program  Design 
Language,  1986 

10.  ANSI/IEEE  Std.  1002  -  IEEE  Standard  Taxonomy  for  Software  Engineering 
Standards,  1987 

1 1 .  ANSI/IEEE  Std.  1008  -  IEEE  Standard  for  Software  Unit  Testing,  1987 

12.  ANSI/IEEE  Std.  1012  -  IEEE  Standard  for  Software  Verification  and  Validation 
Plans,  1987 

13.  ANSI/IEEE  Std.  1016  -  IEEE  Recommended  Practice  for  Software  Design 
Descriptions,  1987 
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14.  IBEEStd.  1028  -  IEEE  Standard for  Software  Renews  and  Audits,  1988 

15.  ANSI/IEEE  Std.  1042  -  IEEE  Guide  to  Software  Configuration  Management,  1988 

16.  ANSI/IEEE  Std.  1058.1  -  IEEE  Standard  for  Software  Project  Management  Plans, 
1987  [PAR  approved  for  revision  October  1993] 

17.  ANSI/IEEE  Std.  1063  -  IEEE  Standard  for  Software  User  Documentation,  1989. 

The  following  standards  in  this  series  were  approved: 

•  IEEE  1045,  Software  Productivity  Metrics,  1992 

•  IEEE  1061,  Standard  for  a  Software  Quality  Metrics  Methodology,  1992 

•  IEEE  1016.1,  Guide  to  Software  Design  Description,  1993 

•  IEEE  1219,  Standard  for  Software  Maintenance,  1993 
Standards  under  development  in  this  series  include: 

•  IEEE  P1016.2,  Guide  to  Software  Design  Descriptions 

•  IEEE  P1044,  Standard  for  Classification  of  Software  Anomalies  (formerly  entitled 
Classification  of  Software  Errors/Faults/Failures) 

•  IEEE  P1059,  Software  Verification  and  Validation 

•  IEEE  P1062,  Software  Acquisition 

•  IEEE  P1074,  Software  Life  Cycle  Processes 

•  IEEE  P1228,  Software  Safety  Plans. 

Development  of  international  software  engineering  standards  by  ISO/IEC  JTC1/SC7  on 
Software  Engineering  is  still  in  its  early  stages.  The  near-term  emphasis  will  be  on  establishing  a 
foundation  on  which  to  build  future  standards.  The  following  standards  projects  are  underway  in 
SCTs  working  groups  [Ref.  Edelstein  1991]: 

•  WG1 — Symbols,  Charts,  and  Diagrams 

Conceptual  framework  for  software  development  diagrams 
Charting  techniques  for  software  development  and  maintenance 
Conventions  for  use  of  symbols  and  icons  in  software  systems 

•  WG2 — System  and  Software  Documentation 

Guidelines  for  documentation  of  computer-based  systems 

•  WG4 — Tools  and  Environments 

Evaluation  and  selection  of  CASE  tools 

•  WG5 — Reference  Model  for  Software  Development 

Reference  model 
Reference  model  overview 

•  WG  6 — Evaluation  and  Metrics 

Software  quality  characteristics 
Software  quality  management 
Requirements/design/testing,  etc. 

•  WG  7 — Life  Cycle  Management 

Software  configuration  management 
Software  life  cycle  management 

•  WG  8 — Integral  Life  Cycle  Processes 

Transfer  of  information  between  life  cycle  phases 

•  WG  9 — Classification  and  Mapping 

Reference  model — mapping  of  relevant  information  systems  engineering 
standards. 
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A  definition  of  software  engineering  life  cycle  processes  has  been  progressed  to  CD  status. 
It  is  intended  to  serve  as  a  reference  point  in  discussions  between  suppliers  and  clients,  and  is  not 
an  attempt  at  defining  a  method.  SC7  plans  to  develop  a  technical  report  on  Software  Process 
Assessment.  Detailed  definitions  of  generic  processes  are  also  underway,  such  as  configuration 
management.  SC7  has  progressed  to  the  IS  level  two  documents  entitled  Software  Product 
Evaluation,  Quality  Characteristics  and  Guidelines  for  Their  Use  (ISO  9126,  1991);  and  User 
Documentation  and  Cover  Information  for  Consumer  Software  Packages  (ISO  9127, 1988). 

Just  as  the  OSI  reference  model  organized  activity  on  communications  standards,  a 
reference  model  is  being  developed  by  SC7/WG9  to  organize  the  work  on  products  and  standards 
for  software  engineering.  It  is  called  the  Standardization  Framework  for  Software  Engineering  and 
is  planned  to  help  identify  where  standards  are  needed  to  create  open  systems  in  the  field  of 
information  systems  engineering.  A  study  in  1991  by  the  Commission  of  the  European 
Community  (CEC)  concluded  that  because  of  the  importance  of  the  information  industries  in  the 
European  Community  (EC),  actions  n.-  rst  be  taken  to  remove  the  barriers  to  free  trade  in  this 
sector.  The  report  established  the  need  for  a  consistent  and  integrated  set  of  information  systems 
engineering  standards  to  open  up  the  closed  markets.  It  also  introduced  the  concept  of  OpenISE, 
information  systems  engineering  without  barriers  to  competition  and  free  trade.  European 
Community  for  Standardization  (CEN)  WG63,  which  began  meeting  in  February  1992,  is  charged 
with  developing  an  action  plan  for  European  standards  in  information  systems  engineering. 
SC7/WG9's  framework  will  play  an  important  part  in  helping  WG63  select  and  prioritize  the 
standards  needed  for  OpenISE.  The  framework  has  only  recently  reached  stability.  [Ref. 
OSN  1993e] 

International  activity  that  will  affect  software  development  is  the  standardization  of  quality 
management  systems.  ISO  9001,  Quality  Systems,  represents  a  concise,  generic  description  of  the 
essential  elements  of  management  systems  for  assuring  quality  in  development,  production,  and 
qualification  with  emphasis  on  the  "what"  over  the  "how."  ISO  9000,  Part  3:  Guidelines  for  the 
Application  of  ISO  9001  to  the  Development,  Supply  and  Maintenance  of  Software,  was  approved 
by  international  ballot  and  adopted  by  TC  176  in  November  1990.  [Ref.  Edelstein  1991] 

A  new  ISO  standard  on  software  quality  was  recently  approved:  ISO  12119,  Information 
Technology:  Software  Packages:  Quality  Requirements  and  Testing,  1993.  It  was  developed 
from  the  German  standard  DIN  66285: 1990  that  defines  the  conditions  for  granting  a  quality  mark 
( Guetezeichen  software).  Currently,  more  than  100  products  exist  with  a  quality  mark. 

There  are  currently  no  standards  specifically  for  the  development  of  expert  systems.  It  is 
not  clear  that  the  development  of  expert  systems  will  need  to  follow  a  different  or  unique  process 
model. 

The  ESPRIT  project  "accueil  de  logiciel  futur"  aims  to  provide  a  knowledge-assisted 
software  process  model  on  top  of  the  PCTE.  [Ref.  Brettnacher  1988] 

Development  methods  tend  to  be  proprietary  and  not  subject  to  standardization.  However, 
one  IEEE  project  (PI  152),  Standard  for  Object  Oriented  Programming  Language  and 
Environment,  is  developing  a  standard  based  on  the  SmallTalk  programming  language  and 
environment 
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4.4  Standards  for  Programming  Interfaces 

Formal  standardization  of  programming  interfaces  includes  new  work  being  conducted  by 
SC21.  A  special  working  group  (SWG)  conducted  a  year-long  effort  (June  1992  to  June  1993)  to 
identify  application  program  interface  (API)  activities  in  relation  to  the  areas  of  standardization  for 
which  SC21  was  responsible,  with  the  view  of  basing  its  work  on  the  framework  provided  by  the 
Reference  Model  for  Open  Distributed  Processing  (CD  10746)  and  recognizing  work  taking  place 
outside  SC21.  The  report  of  the  SWG  [SC21  N  804S]  and  its  recommendations  [SC21  N  8052] 
on  gathering  information  about  priorities  and  plans  for  standardization  of  programming  interfaces 
were  accepted  by  SC21  and  forwarded  to  JTC1. 

SC21  dissolved  this  SWG  and  replaced  it  with  another  to  receive  liaisons  from  other 
groups  in  response  to  the  June  1993  report  [SC21  N  8045],  to  prepare  appropriate  responses,  and 
to  prepare  SC21  contributions  to  a  joint  working  group  (JWG)  between  SC21  and  SC22,  should 
JTC1  approve  its  formation.  SC21  welcomed  establishment  of  active  liaison  with  X/Open  and 
requested  C-liaison  status  for  X/Open  on  the  topic  of  APIs  and  related  architectural  frameworks. 
The  initial  meeting  of  the  new  SWG  was  held  in  November  1993. 

Fast-track  DISs  are  expected  to  be  submitted  by  IEEE  on  common  ASN.l  object 
management  APIs  for  X.400  and  Directory  Service  APIs;  X.400-based  electronic  messaging  API; 
and  Directory  Service  API.  APIs  are  addressed  in  more  detail  in  Sections  15.1.3  and  15.2  in 
connection  with  application  portability. 

4.5  Assessment  of  Coverage  by  Standards 

There  are  international  standards  for  most,  but  not  all,  of  the  commonly  used  programming 
services.  Although  ISO  and  the  US  Government  have  adopted  ANSI  X3.159,  Programming 
Language  C,  there  ate  potential  compatibility  problems  between  C  and  C++.  The  other  standards 
are  stable.  However,  Ada  is  undergoing  a  revision  process  and  some  aspects  of  the  current 
language  may  not  be  upwardly  compatible  with  its  successor,  Ada  9X.  Moreover,  COBOL  is 
currently  limited  in  real-time,  operating  system,  and  communications  components. 

There  is  no  standard  set  of  guidelines  for  using  the  features  of  the  Ada  programming 
language;  without  guidance,  applications  written  in  Ada  may  have  unpredictable  portability.  Ada 
bindings  are  needed  for  many  interfaces,  such  as  graphical  user  interface  (GUI)  toolkits,  OSI 
Application  Layer  functionality,  CASE  Data  Interchange  Format  (CDIF),  Standard  Generalized 
Markup  Language  (SGML),  X.25,  and  Transmission  Control  Protocol/In temet  Protocol  (TCP/IP). 
They  have  been  completed  for  GKS  (ISO  8651-3),  PHIGS  (ISO  9593-3),  and  SQL  (ISO 
9075:1992),  and  are  at  the  DIS  level  for  GKS-3D  (DIS  8806-3)  and  CGI  (DIS  9638-3).  Ada 
bindings  for  X,  SQL,  and  IRDS  (ISO  10728  WDAM  2)  are  underway.  IEEE  P1003.5  is  currently 
defining  Ada  bindings  only  to  POSIX.l  and  not  to  the  other  POSIX  standards.  P1003.20  is 
reported  to  be  developing  an  Ada  binding  to  POSIX  real-time  extensions. 

All  fourth  generation  languages  (4GLs)  are  proprietary.  Portability  of  4GL  products 
requires  open  standardization  of  languages  and  bindings. 

Standards  have  not  been  developed  for  languages  used  for  certain  technologies  and 
application  areas.  These  areas  might  include  languages  used  in  artificial  intelligence  (standards  for 
LISP  and  Prolog  have  been  developed  but  not  for  other  languages)  and  used  for  interfaces  to 
specific  COTS/NDI  software.  LISP  is  more  popular  in  the  United  States  while  Prolog  is  more 
popular  in  the  United  Kingdom  and  Europe,  posing  potential  interoperability  problems. 
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Standards  for  software  development  environments,  including  CASE  tools  and 
environments,  are  in  the  early  phases  of  development  Some  are  currently  restricted  to  interfaces 
between  tools  while  others  address  entire  environments.  Standards  are  needed  for  integrated 
(computer-aided)  software  engineering  environments  (ISEEs)  and  tools.  These  include  systems 
and  programs  for  automated  assistance  in  the  development  and  maintenance  of  software,  such  as 
tools  for  requirements  specification  and  analysis,  for  design  work  and  analysis,  for  creating 
program  code,  for  testing,  for  documenting,  for  prototyping,  and  for  group  communication.  The 
interfaces  among  these  tools  include  services  for  storing  and  retrieving  information  about  systems 
and  exchanging  this  information  among  the  various  system  development  environment  components. 
ECMA’s  PCTE  and  associated  reference  model  is  widely  supported  by  vendors  in  Europe.  The 
Ada  Programming  Support  Environment  (APSE)  specifications  can  be  mapped  to  this  reference 
model.  The  work  of  defining  interfaces  among  various  software  components  is  still  incomplete 
and  in  a  state  of  flux.  For  example,  there  is  as  yet  no  consensus  on  the  type  of  data  model 
necessary  to  support  the  information  structures  for  the  environment.  The  extent  to  which 
environments  such  as  PCTE  and  CAIS  can  evolve  and  be  tailored  is  unknown.  Moreover,  CAIS 
is  suffering  from  a  dearth  of  conforming  commercial  products.  Tool  interfaces  based  on 
commercial  products  may  lack  flexibility. 

Standards  for  KBS  do  not  exist  Software  repository  standards  to  facilitate  reuse  do  not 
yet  exist  This  could  have  an  adverse  effect  on  a  COTS/NDI  acquisition  strategy  by  making  NDI 
software  difficult  to  identify. 

Software  engineering  standards  that  address  the  software  development  process  and 
development  methods,  and  ultimately  software  quality,  are  in  the  early  phases  of  the  international 
standardization  process.  It  will  be  at  least  3  yearn  before  a  foundation  for  these  standards  is 
established.  To  date,  none  addresses  the  development  of  expert  systems. 
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5.  USER  INTERFACE  SERVICE  STANDARDS 


5.1  Requirements  for  User  Interface  Services 

User  interface  services  specify  the  human-computer 

interface  (HCI),  terminal  management  services,  and  interactions 
with  virtual  terminals.  Such  standard  interfaces  are  needed  to 
ensure  a  high  degree  of  application  portability  and  to  provide  a 
consistent  look  and  feel  across  multiple  implementations.  An 
overview  of  standards  for  user  interfaces  is  given  in  Table  3. 

The  user  interface  services  provide  a  consistent  way  for 
the  people  who  develop,  administer,  and  use  a  system  to  gain 
access  to  applications  programs,  operating  systems,  and  various 
system  utilities.  An  information  system  architecture  addresses 
not  only  the  technical  features  of  the  user  interface  but  also  the 
human  engineering  considerations.  User  interface  services 
address  client-server  operations,  object  definition  and 
management,  window  management,  and  dialog  support 

HCI  standardization  is  based  mi,  but  extends  beyond,  the  selection  of  a  commercial  off-the- 
shelf  (COTS)  graphical  user  interface  (GUI).  While  the  GUI  provides  a  standard  application 
program  interface  (API)  and  style  guide,  application  designers  are  only  provided  with 
recommended  generic  approaches.  Varying  interpretations  of  the  GUI  style  guide  and  of  users’ 
needs  can  still  result  in  dissimilar  HCIs  among  applications  developed  by  independent 
organizations.  Adding  to  the  standardization  problem  is  the  fact  that  COTS  GUI  packages  do  not 
address  special  issues  such  as  map  graphics.  [Ref.  DoD  HCI  Style  Guide  1992] 

5.2  Standards  for  User  Interface  Services 

Human -computer  interfaces  comprise  two  levels  of  standardization.  One  level  is  the 
specification  of  how  computer  system  elements  shall  interface  to  display  terminals  and  other  output 
devices  with  a  capability  for  human  interaction.  The  second  level  is  the  look,  feel,  and  layout  of 
the  display  screens,  keyboards,  and  other  elements  of  the  workstation  that  define  the  way 
information  is  displayed  and  how  the  user  interacts  with  that  information. 

Table  3.  Status  Overview  of  Key  Human  Computer  Interface  Standards 


Key:  %  High  Evaluation  Source:  [Ref.  APP 19S3] 

O  Average  Evaluation 
Blank  Low  Evaluation 


LOC  -  Level  of  consensus 

PAV  -  Product  availability 

CMP  -  Completeness 

MAT  -  Maturity 

STB  -  Stability 

DFU  -  Da  facto  usage 

PRL  -  Probtsma/Hmitations 
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5.2.1  HC1  Standards  Organizations 

The  standards  work  in  ISCVIEC  covers  both  levels  of  HCL  These  standards  activities  seek 
to: 

•  Provide  consistency — in  screen  and  keyboard  layout,  terminology,  semantics,  user 
action,  and  syntax — across  and  within  manufacturers,  systems,  and  applications 

•  Enhance  comfort  and  well-being 

•  Enhance  usability21 

•  Assist  in  product  procurement  and  evaluation. 

Specifically,  ISO/IEC  JTC1/SC18  (Document  Processing  and  Related  Communication, 
formerly  Text  and  Office  Systems)  has  a  working  group,  SC18/WG9  (User  System  Interfaces  and 
Symbols),  that  is  developing  standards  to  support  keyboard  layout,  user  interfaces,  cursor  control, 
and  icons  (e.g.,  symbols)  to  be  displayed.  In  addition,  the  Ergonomics  Technical  Committee 
(TC159)  of  ISO  is  addressing,  through  SC4  (Signals  and  Controls)  and  WG5  (Software 
Ergonomics  and  Man-Machine  Dialogue),  standards  for  dialogue  interface,  coding,  formatting, 
menus,  and  usability  assurance.  Other  areas  of  standardization  related  to  the  user  interface  of 
information  systems  being  addressed  by  ISO  are  [Ref.  Bevan  1989]: 

•  Documentation  (JTC1  SC7/WG2) 

•  Software  quality  characteristics  (JTC1  SC7/WG3) 

•  Text  interchange  (JTC1  SC18AVG4) 

•  Terminal  management  (JTC 1  SC2 1/WG4) 

•  Form  Interface  Management  System  (FIMS)  (JTC1  SC22) 

•  POSIX  (JTC1  SC22/WG15) 

•  Commands  for  interactive  text  searching  (TC46/SC4) 

•  Software  quality  assurance  (TC176  SC2/WG5). 

Other  groups  working  on  HCI  standards  include  [Ref.  Reed  1991]: 

•  ITU-TS  Study  Group  X,  Working  Party  1,  Man-Machine  Language 

•  Human  Factors  Society,  Human  Computer  Interaction  Committee 

•  ANSI  X3 V 1 .9,  User  System  Interfaces  and  Symbols 

•  IEEE  Steering  Committee  on  User  Interface  (SCWUI) 

•  TFFF.  Project  1201,  Window  Interface  for  User  and  Application  Portability 

•  Open  Software  Foundation  (OSF)'s  Motif  Graphical  User  Interface  (GUI) 

•  UNDC  International  (UI)  OPEN  LOOK  GUI  [Ref.  SUN  1990] 

•  Information  Industry  Association 

-  Voice  Messaging  User  Interface  Forum  (VMUIF) 

-  Voice/Fax  User  Interface  Forum  (VFUIF). 

5.2.2  Visual  Display  Terminal  (VDT) 

Work  has  been  underway  for  several  years  on  the  hardware  user  interface  standards,  now 
known  and  approved  as  Human  Factors  Society  (HFS)/ANSI  100-1988,  Human  Factors 
Engineering  of  Video  Display  Terminal  Workstation  Standard.  To  date,  however,  there  has  been 
relatively  little  work  on  software  user  interface  standards.  The  HFS  Technical  Standards  Common 


21  As  used  in  SC18/WG5,  usability  of  a  product  is  defined  as  tbe  degree  to  which  specific  users  can  achieve 
specified  goals  in  a  particular  environment  effectively,  efficiently,  comfortably,  and  in  an  acceptable  manner. 
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Human-Computer  Interaction  was  formed  in  1985  to  evaluate  the  feasibility  of  software  user 
interface  standards.  It  has  submitted  a  fully  reviewed  document  on  menu-based  dialogue  design  to 
the  ISO  Working  Group  on  Software  Ergonomics  (TC159/SC4/WG5).  [Ref.  Reed  1991] 

SC18/WG9  seeks  to  develop  a  user  interface  standard  that  would  address  names  of  basic 
objects  and  actions,  user  guidance,  dialogue  interaction,  and  graphical  symbols  used  on  screens. 
The  standard  is  DIS  9995:  Information  Technology  -  Keyboard  Layouts  for  Text  and  Office 
Systems.  The  current  parts  represent  a  recombination  of  material  formerly  in  21  parts: 

•  DIS  9995-1  (Part  1),  General  Principles  Governing  Keyboard  Layouts 

•  DIS  9995-2  (Part  2),  Alphanumeric  Section 

•  DIS  9995-3  (Part  3),  Common  Secondary  Layout  of  Alphanumeric  Zone  of 
Alphanumeric  Section 

•  DIS  9995-4  (Part  4),  Principles  Governing  the  Placement  of  Characters  and  Symbols 
on  Keys 

•  DIS  9995-5  (Part  5),  Editing  Section 

•  DIS  9995-6  (Part  6),  Functional  Section 

•  DIS  9995-7  (Part  7),  Symbols  Used  to  Represent  Functions 

•  DIS  9995-8  (Part  8),  Allocation  of  Letters  to  the  Keys  of  a  Numeric  Keyboard. 

SC18/WG9  has  also  distributed  working  drafts  of  two  components  of  an  as-yet 

unnumbered  standard  for  icons  used  on  screens.  The  standard  is  intended  to  apply  to  systems 
implementing  the  desktop  metaphor,  although  icon  systems  suitable  for  other  application  fields 
may  be  future  subjects  of  standardization.  [Ref.  Billingsley  1990]  ANSI  X3V1.9  is  the  US 
Technical  Advisory  Group  to  WG9. 

TC159  SC4/WG5  is  developing  a  standard  (ISO  9241)  for  VDTs  that  addresses  office  task 
requirements,  visual  requirements,  keyboard  ergonomics,  work  place  design  and  environment, 
surfaces  and  filters,  use  of  color  and  graphics,  non-keyboard  input  devices,  usability,  coding, 
formatting,  and  terminology.  The  status  of  the  parts  to  ISO  9241,  Ergonomic  Requirements  far 
Office  Work  with  Visual  Display  Terminals ,  is  as  follows: 

•  ISO  9241-1  (Part  1 ),  Introduction,  1992 

•  ISO  9241-2  (Part  2),  Task  Requirements,  1992 

•  ISO  9241-3  (Part  3),  Visual  Display  Requirements,  1992 

•  DIS  9241-4  (Part  4),  Keyboard  Requirements 

•  CD  9241-5  (Part  5),  Workstation  Layout  and  Postural  Requirements 

•  CD  924 1 -6  (Part  6),  Environmental  Requirements 

•  CD  9241-7  (Part  7),  Display  Requirements  with  Reflections 

•  CD  9241-8  (Part  8),  Requirements  for  Displayed  Colors 

•  CD  924 1 -9  (Part  9),  Requirements  for  Non-Keyboard  Input  Devices 

•  WD  9241-10  (Part  10),  Dialogue  Principles 

•  CD  9241-11  (Part  1 1),  Usability  Statements 

•  CD  9241-12  (Part  12),  Presentation  of  Information 

•  WD  9241-13  (Part  13),  User  Guidance 

•  CD  9241-14  (Part  14),  Menu  Dialogues 

•  WD  9241-15  (Part  15),  Command  Dialogues 

•  WD  9241-16  (Part  16),  Direct  Manipulation  Dialogues 
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•  WD  9241-17  (Part  17),  Form-Fitting  Dialogues 

•  XX  9241-18  (Part  18),  Question  and  Answer  Dialogues  (CD  expected  in  1994) 

•  XX  9241-19  (Part  19),  Natural  Language  Dialogues  (CD  expected  June  1994). 

5.2.3  Virtual  Terminal  (VT) 

VT  standards  (ISO  9040  and  9041)  define  a  communications  protocol  between  a  terminal 
and  its  host  in  terms  of  a  conceptual  terminal,  where  the  mapping  from  the  conceptual  terminal  to 
die  physical  device  is  an  implementation  issue  outside  the  standard.  The  VT  standards  specify  how 
terminal  systems  and  host  applications  on  a  network  can  communicate  without  requiring  one  side 
to  know  the  terminal  characteristics  of  the  other  aide.  The  capabilities  and  constraints  of  different 
types  of  terminal-application  dialogues  are  defined  by  a  VT  profile. 

Several  classes  of  display  and  data  manipulation  capabilities  will  eventually  be  addressed 
by  VT  standards  [Ref.  OSN  1989b]: 

•  Basic  class,  for  textual  data  in  a  rectangular  army  of  character  boxes 

•  Forms  class,  similar  to  the  basic  class,  but  with  the  ability  to  define  fields  with  control 
over  data  entry 

•  Graphics  class,  for  geometric  data  such  as  lines  and  circles  (as  defined,  for  example, 
in  GKS) 

•  Text  class,  for  structured  data  such  as  provided  by  Office  Document  Architecture 
(OD  A)  data  streams 

•  Image  class,  for  bit-mapped  displays. 

The  1990  revision  of  ISO  9040  and  9041  incorporates  an  amendment  (AMI)  to  define  enhanced 
access  rules,  structured  control  objects,  blocks,  fields,  and  reference  information  objects. 

Amendment  2  [SC21  N  7243,  June  1992]  for  ISO  9040/9041  enhances  the  capability  of 
the  virtual  terminal  environment  (VTE)  by  use  of  the  Association  Establishment  and  Negotiation 
functions,  extends  the  set  of  objects  and  operations  provided  by  the  Data  Transfer  function,  and 
enhances  error  handling  capabilities  of  the  service  provider.  Amendment  2  provides  additional 
functionality  for  ripple  mode  editing  (insertion,  deletion,  and  copy  operations  for  a  Display 
Object),  exception  reporting  (provides  mechanisms  by  which  non-fatal  exception  conditions  may 
be  reported  by  the  VT  service  provider  to  both  VT  users),  and  retention  of  VT  context  across 
Negotiation  (retention  of  the  information  stored  in  selected  VT  Objects — Display  Object  and 
Control  Objects — to  be  retained  between  successive  VT  environments  within  the  lifetime  of  a  VT 
association). 

ISO  9041-2,  VT  Protocol  Implementation  Conformance  Statement  (PICS)  Proforma 
reached  IS  status  in  February  1992.  In  addition,  registration  authority  procedures  have  been 
developed  for  the  VTE  and  VT  Control  Objects:  ISO  9834-4  and  ISO  9834-5,  respectively. 
Finally,  a  guide  to  VT  standards  has  been  developed  by  SC21/WG5  [SC21  N  3365, 
December  1988].  Conformance  Test  Suite  for  the  VT  Protocol  -  Part  1:  Test  Suite  Structure  and 
Test  Proposes  (ISO  10739-1),  August  1992,  has  also  been  developed. 

Intercom  Data  Systems  (IDS)  of  Woking  (UK)  claims  the  first  commercial  implementation 
of  the  VT  standard:  VirtuOSL  [Ref.  OSN  1993b] 

VT  profiles  are  being  developed  by  two  regional  workshops:  the  EWOS  and  the  NIST 
OSE  Implementor's  Workshop  (OIW).  EWOS  is  working  on  synchronous-mode  profiles  that  are 
based  on  a  two-way  exchange  with  a  single  display  object  requiring  the  exchange  of  an  access 
token.  EWOS  profiles  include  [Ref.  SGFS  N  100  1992]: 
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•  FVT1  nn,  Register  of  VTE-profiles,  pDISP  1 1 184 

•  FVT2  nn.  Register  of  Control  Object  Type  Definitions,  DISP 1 1 185 

•  FVT3  nn.  Register  of  Assignment  Type  Definitions,  pDISP  11186. 

The  OIW  is  developing  asynchronous-mode  profiles.  These  are  based  on  a  character-by¬ 
character  interworking,  in  which  there  are  two  display  objects,  but  the  user  at  each  end  is  allowed 
to  update  only  one  of  the  objects.  OIW  profiles  include  Telnet,  Transparent,  Forms,  Scroll, 
Paged,  and  X.3/X.28/X.29  [packet  assembler/disassembler  (PAD)].  Individual  parts  of  the 
profiles  for  Virtual  Terminal  are  identified  in  Table  4. 


Table  4.  Registration  Pro  filet  (FVTs)  and  Application  (AVTs)  for  Virtual  Terminal 


pDISP  11184 

Part  1 
Part  2 
Parts 
Part  4 
PartS 
Parts 
Part  7: 
DISP  11185 

Parti: 
Part  2: 
PartS: 


Part  4: 
Part  5: 
Pait  6: 
Part  7: 
PartS: 
Part  9: 
Part  10: 
Part  11: 
Part  12: 
Part  13: 
Part  14: 
Part  15: 
Part  16: 
Part  17: 
pDISP  11186 
Part  1: 
DISP  11187 

Parti: 
Part  2: 
PartS: 
Part  4: 
PartS: 
Part  7: 
Part  8: 
PartS: 
_ Part  10: 


ISPa  FVT  inn  -  Virtual  Terminal  Basic  Class  •  Register  of  VTE  Profits  (DISPs  expected  in 
1994  or  1995) 

FVT  121  -  S-mode  Forms  VTE  Profile,  1993 

FVT  122  -  S-mode  Paged  VTE  Profile,  1993 

FVT  111  -  A-mode Telnet  Profile 

FVT  1 12  -A-mode  Scroll  VTE  Profile 

FVT  113  -  A-mode  CCfTT  X.3  PAD  Interworking 

FVT  114-  A-mode  Transparent  VTE  Profile 

FVT  115 -A-mode  Generalized  Telnet  VTE  Profile,  1993 

ISPs  FVT  2nn  -  Virtual  Terminal  Basic  Class  -  Register  of  VT  Control  Objects  (Parts  1-1 1  are 
DISPs;  the  others  are  pDISPs) 

FVT  211,  FVT  212,  Sequenced  and  Unsequenced  Application  Control  Objects,  1993 

FVT  213,  FVT  214,  Sequenced  and  Unsequenced  Terminal  Control  Objects,  1993 

FVT  215,  FVT  216,  Application  RIO  Record  Locating  Control  Object  and  Terminal  RIO  Record 

Notification  Control  Object,  1993 

FVT  217,  Horizontal  Tabulation  Control  Object,  1993 

FVT  218,  Logical  Image  Control  Object,  1993 

FVT  219,  Status  Message  Control  Object,  1993 

FVT  220,  Entry-control  Control  Object,  1993 

FVT  221,  Forms  Field  Entry  Instruction  Control  Object  (FEICO)  No.  1, 1993 
FVT  222,  Paged  Field  Entry  Instruction  Control  Object  (FEICO)  No.  1, 1993 
FVT  231,  Forms  Field  Entry  Pilot  Control  Object  (FEPCO)  No.  1, 1993 
FVT  232,  Paged  Field  Entry  Pilot  Control  Object  (FEPCO)  No.  1. 1993 
FVT  251,  Terminal  Condteons  Control  Object  No.  1 
FVT  2111,  Waiting  Time  Control  Object  (pDISP  expected  1995) 

FVT  21 12,  Printer  Control  Object,  1 993 
FVT  2113,  Field  Definition  Control  Object,  1993 
FVT  21 14,  Terminal  Signal  Titles  Control  Object,  1 993 
FVT  2115,  Form  Help  Text  Control  Object,  1993 

ISPs  FVT  3nn  •  Virtual  Terminal  Basic  Class  -  Register  of  Assignment  Type  Definitions 
FVT  321,  Font  Assignment  Type  No.  1 

ISPs  AVT  In,  AVT  2n  -  Virtual  Terminal  Basic  Class  -  Application  Profiles  (Parts  3-10  are 
pDISPs;  DISPs  expected  in  1994  or  1995) 

AVT  22,  S-mode  Forms  Application  Profile,  1993 
AVT  23,  S-mode  Paged  Application  Profile,  1993 
S-mode  ISPICS  Requirements  List  No.  1 

S-mode  ISPICS  Requirements  (IPRL)  List  No.  1,  Supporting  Layers  List  No.  1 
AVT  13,  A-mode  Scroll  Application  Profile 
AVT  14,  A-mode  CCITT  X.3  PAD  Application  Profie 
AVT  15,  A-mode  Transparent  Application  Profile 
AVT  16,  A-mode  Generalized  Telnet  Application  Profile,  1993 
AVT  17.  A-mode  ISPICS  Requirements  List  No.  1 
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In  May  1991,  SC21/WG5  generated  a  document  for  study  and  comment  on  the  possibility 
of  supporting  interactive  access  to  ODA  data  structures  through  an  extension  of  the  VT  protocol. 
[Ref.  SC21  N  6227  1991] 

5.2.4  Terminal  Management  (TM) 

SC21/WG5  initiated  a  program  for  developing  standards  f,  directed  at  support  for  multi¬ 
function  workstations,  which  has  now  been  terminated.  The  role  of  TM  was  to  support  the  control 
and  manipulation  of  logical  devices  typically  associated  with  workstations.  Logical  devices  were 
defined  in  TM  to  provide  a  mapping  between  transferred  data  such  as  ODA  documents  and  the 
physical  devices  such  as  a  workstation  screen,  taking  into  account  control  information  such  as 
synchronization  and  the  use  policy  of  a  particular  application.  TM  was  related  to  work  on 
Document  Transfer  and  Manipulation  (DTAM,  ITU-TS);  user  interface  standards  (SC  18);  Forms 
Interface  Management  System  (FIMS,  SC22);  and  window  management  (SC24). 

The  TM  standard  was  to  have  consisted  of  three  parts:  TM  Model  (CD  10184-1.2),  TM 
Service  (WD  10184-2),  and  TM  Protocol  (WD  10184-3).  The  first,  TM  Model,  progressed  to 
second  CD  status  in  June  1991  and  was  expected  to  progress  to  DIS  in  July  1992  and  IS  in  July 
1993.  CD  status  for  the  other  two  was  expected  in  December  1992;  however,  in  August  1993  the 
project  was  cancelled.  [Ref.  SC21  N  8081  1993]  Reasons  for  the  cancellation  include  lack  of 
resources  and  the  fact  that  X-Windows  is  now  progressing  on  a  fast-track  ballot 

5.2.5  Status  of  X-Windows 

The  X-Windows  standard  effort,-based  user  interface  standard,  began  as  a  de  facto 
standard  developed  at  the  Massachusetts  Institute  of  Technology).  It  was  developed  by  Project 
Athena  and  die  Laboratory  for  Computer  Science  at  MIT  with  funding  and  participation  by  Digital 
Equipment  Corporation  (DEC)  and  IBM.  [Ref.  McCartney  1987]  Currently  in  Version  1 1 
(Release  5),  X-Windows  sets  a  standard  to  provide  portability  of  information  across  different 
hardware  and  operating  systems.  In  contrast  to  the  kernel-based  architecture  of  traditional 
windowing  systems,  it  has  a  network-based  architecture.  [Ref.  Stoffel  1989;  Oldenburg  1989] 

X-Windows  is  a  graphical  user  interface  standard  that  enables  a  user  to  view  and  gain 
access  to  multiple  computer  applications  from  a  single  window  or  multiple  windows  on  a  display 
screen.  X-Windows  is  based  on  a  client-server  architecture  that  allows  applications  and  resources 
to  be  distributed  across  a  network.  The  X-server  is  a  software  program  resident  on  a  user’s 
display  unit  that  acts  as  an  intermediary  between  the  user  and  applications  running  on  a  local  or 
remote  system.  The  applications  are  referred  to  as  X-clients.  These  applications  access  the  display 
unit  by  sending  messages  to  the  X-server,  which  is  then  able  to  perform  the  two-dimensional 
drawing  of  lines,  shapes,  and  text  The  X-server  also  maintains  complex  data  structures  such  as 
specific  windows,  cursors,  and  fonts  that  can  be  referenced  and  used  by  applications.  Input  from 
the  keyboard  and/or  mouse  is  collected  by  th.  X-server  and  passed  to  local  and/or  remote 
applications  for  processing.  [Ref.  IGOSS  1993] 

Some  features  added  in  Release  5  include: 

•  Internationalization  that  allows  programmers  to  develop  applications  that  can  be 
adapted  to  different  native  languages,  local  customs,  and  character  encodings 

•  PHIGS  Extension  for  X  (PEX) 

•  Font  server  to  manage  fonts  separately  from  the  X  server. 
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Release  6  is  expected  to  emphasize  three-dimensional  extensions  to  X  and  embed  the  ability 
to  drag  or  drop  icons  onto  programs,  but  it  is  not  expected  for  some  time.  Since  MIT  believes  it  is 
time  X  developments  moved  into  the  commercial  arena,  the  X  Consortium  is  planned  to  become  a 
not-for-profit  company  funded  by  membership  dues.  [Ref.  OSN  19921] 

The  strategic  direction  in  ISO  for  OSI  support  of  windowing  environments  was  embedded 
in  the  Terminal  Management  project,  whose  cancellation  was  due,  in  part,  to  the  rapidly  growing 
demand  for  the  X-Windows  system.  This  demand  is  being  satisfied  by  the  use  of  X- Windows 
clients  and  servers  collocated  in  the  same  machine  or  over  LANs  using  protocols  such  as  TCP/IP. 
Some  large  user  communities  are  now  trying  to  run  X-Windows  over  wide  area  networks  (WANs) 
and  in  some  cases  plan  to  install  TCP/IP  networks  in  competition  with  the  emerging  OSI  networks 
based  on  ISO  protocols.  [Ref.  SC21  N  41S9  1989] 

An  efficient  OSI  compatible  way  of  supporting  the  X-Windows  System  is  needed.  While  it 
would  be  preferable  from  the  standards  point  of  view  to  rewrite  X-Windows  completely,  this 
would  require  developmental  effort  and  dedicated  expertise  that  does  not  appear  to  be  available. 
Further,  by  the  time  any  such  standard  becomes  complete,  it  would  likely  be  too  late  to  gain 
acceptance.  Instead,  in  April  1991,  ANSI  X3  announced  the  approval  of  a  new  project  on 
X-Windows  System  Data  Stream  Definition.  Part  4  of  this  draft  standard  (X3.219)  represents  the 
mapping  of  Version  1 1  of  X-Windows  (X 1 1)  onto  OSI  services  using  the  OSI  Application  Layer 
naming  and  addressing  conventions.  [Ref.  X3  1991i]  The  work  has  progressed  well,  and  a  four- 
part  standard  has  gone  out  to  ballot  in  the  X3H3  group.  The  four  parts  are: 

•  Part  1,  Functional  Specification 

•  Part  2,  Data  Stream  Encoding 

•  Part  3,  Keysym  Encoding 

•  Part  4,  Mapping  onto  OSI  Services. 

Parts  1  through  3  define  the  X-Windows  data  stream  definition,  and  Part  4  defines  the  mapping 
(using  an  OSI  skinny  stack)  of  X-Windows  data  streams  onto  OSI  application  service  elements 
(e.g.,  ACSE)  and  Presentation  Service.  When  X3.219  is  approved  by  ANSI,  it  will  be  submitted 
to  ISO  for  fast  track  balloting  through  SC24.  [Ref.  OSN  19921;  IGOSS  1993] 

Because  XI 1  has  limited  two-dimensional  (2D)  graphics  capabilities,  a  consortium  of 
organizations  under  the  auspices  of  MIT  has  developed  X3D-PEX,  an  extension  to  the  XU 
standard  that  supports  the  Programmers'  Hierarchical  Interactive  Graphics  System  (PHIGS)  and 
the  three-dimensional  version  of  the  Graphical  Kernel  System  (GKS-3D).  [Ref.  Clifford  1988] 
PHIGS  and  GKS  are  discussed  in  Sections  8.2  and  8.3,  respectively. 

FIPS- 158,  X-Windows  User  Interface,  was  approved  in  May  1990  as  a  US  mandatory 
standard.  It  is  based  on  Release  3  of  Version  1 1  of  the  MIT  X-Windows  de  facto  standard  and  is 
compatible  with  Release  4,  which  is  currently  available  from  most  vendors.  Since  the  de  facto 
standard  is  now  in  Release  5,  NIST  plans  to  issue  FIPS  158-1  soon.  [Ref.  Kuhn  1991] 

The  Display  Industry  Association  (DIA)  recently  released  the  Alpha  Windows  Standard  for 
displaying  applications  software  in  windows  on  low-cost  terminals.  The  Alpha  standard  is  an 
alternative  to  the  X-Windows  standard  where  graphics  are  not  required.  The  specification  was 
completed  in  August  1991  [Ref.  OSN  1992g],  and  the  first  commercial  shipments  of  terminals  and 
software  complying  with  the  Alpha  Windows  standard  arrived  in  July  1922. 

Although  the  X-Windows  system  is  a  standard  for  user  interfaces  in  a  distributed 

environment,  it  has  no  single  GUI  component  It  was  a  deliberate  policy  of  the  writers  of  X  to 
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provide  a  generic  mechanism  that  could  be  used  to  create  particular  user  interfaces.  A  GUI  is  built 
from  two  main  parts: 

•  The  toolkit  that  provides  windows  on  die  screen 

•  The  window  manager  that  gives  the  user  control  over  the  display. 

Motif  and  OPEN  LOOK,  two  GUI  products  that  extend  the  user  interface,  were  competing  to 
become  the  de  facto  standard.  [Ref.  OSN 19921] 

A  new  body  is  forming  to  promote  X-Windows.  The  X  Industry  Association  (XIA)  will 
likely  focus  on  marketing  X-Windows  and  competing  with  Microsoft’s  Windows  NT  and  the 
Alpha  Windows  standard.  XIA’s  exact  relationship  with  the  X  Consortium  is  not  yet  clear.  [Ref. 
OSN  1993a] 

The  US  DoD  is  planning  to  recommend  a  GUI  that  provides  a  consistent  look  and  feel 
across  all  DoD  corporate  information  applications  and  environments.  The  GUI  is  to  be  based  on 
FIPS  Pub  158  (X-Windows/Xl  1)  and  will  incorporate  features  and  functionality  developed 
through  open,  public-consensus  forums,  such  as  the  IEEE  P1201  committee.  A  recommendation 
for  die  GUI  has  been  developed  by  a  multi- Service/ Agency  working  group  and  is  contained  in  the 
draft  version  of  the  Recommended  Department  of  Defense  Human  Computer  Interface  (HCI)  Style 
Guide  for  Corporate  Information  Management,  July  1993  (see  Section  5.3).  [Ref. 
CALS/CE  1992] 

5.2.6  User  Interface  Reference  Models 

FIPS-158  comprises  the  first  three  layers  (Layers  0-2)  of  the  User  Interface  Reference 
Model  developed  by  NIST.  [Ref.  Kuhn  1990]  The  NIST  Model  consists  of: 

•  Layer  0:  Data  Stream  Encoding 

•  Layer  1:  Data  Stream  Interface,  X-Library  (Xlib) 

•  Layer  2:  Subroutine  Foundation,  X-Toolsot  (Xt)  Intrinsics 

•  Layer  3:  Toolkit 

•  Layer  4:  Dialogue 

•  Layer  5:  Presentation 

•  Layer  6:  Application. 

Layer  0  is  an  X-Protocol  for  messages  between  client  and  server.  It  equates  with  ANSI 
X3.196,  XI 1  Data-Stream  Encoding  for  Window  Management.  Layer  1  is  a  library  interface  that 
provides  a  C  language  interface  to  the  X-Protocol,  Layer  2  consists  of  basic  functions  for 
controlling  windows  and  acts  as  a  tool  kit  for  builder.  [Ref.  Kuhn  1990] 

NIST  Reference  Model  Layers  3  through  5,  while  not  part  of  FIPS-158,  are  the  subject  of 
IEEE  projects.  Layer  3  is  equivalent  to  IEEE  Project  1201.1,  Uniform  Application  Program 
Interface,  Graphical  User  Interfaces,  Draft  3,  February  1992.  It  defines  a  uniform  application 
program  interface  that  can  be  used  by  implementors  of  GUI  applications  to  develop  computer 
programs  that  are  portable  across  multiple  window  systems  and  user  interface  toolkits,  such  as 
OSF/Motif,  OPEN  LOOK,  Microsoft  Windows,  OS/2  Presentation  Manager,  and  Apple 
Macintosh. 

IEEE  Working  Group  PI 295.1  is  working  on  a  source  code  level  interface  to  an 
X-Window  System  Toolkit  graphical  user  interface  environment  based  on  the  OSF  Motif 
Application  Environment  Specification  User  Environment  (see  Section  5.2.7).  It  includes  a 
C  language  API  consistent  with  IEEE  PI  20 1.2.  The  draft  standard  is  entitled:  Drift  Standard  for 
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Information  Technology  -  X-Windows  System  Graphical  User  Interface,  Part  1:  Modular  Toolkit 
Environment  (IEEE  P1295. 1).  P1295. 1  provides  a  toolkit  of  functions  and  objects  for  developing 
the  API  for  a  GUI.  Use  of  P1295.1  in  conjunction  with  FIPS  1S8  implementations  of 
X-Windows  will  provide  a  complete  GUI  but  without  the  management  capabilities  that  can  be 
provided  in  dialog  and  presentation  tools  (Layers  4  and  S)  such  as  User  Interface  Management 
Systems  (UIMS).  NIST  expects  P129S.1  to  advance  from  de  facto  to  de  jure  status  in  a  relatively 
short  time.  [Ref.  APP  1993,  pp.  30-31]  It  passed  its  first  ballot  with  only  three  negative  votes 
and  was  expected  to  reach  formal  IEEE  standard  status  as  early  as  December  1993. 

Layers  4  and  5  are  addressed  respectively  by  the  User  Interface  Language  and  the  UIMS 
work  of  IEEE  Project  1201.3  and  are  still  in  the  research  stage.  IEEE  has  formed  a  study  group, 
but  not  a  working  group,  for  these  efforts. 

The  GUI  part  of  the  IEEE  P1201  Reference  Model  is  not  included  in  the  NIST  Reference 
Model.  The  GUI  is  the  subject  of  IEEE  Project  1201.2,  Driveability  Guide ,  which  provides  a 
recommended  practice  for  minimal  commonality  for  window  systems  (see  Section  15.1.3.3). 
[Ref.  Kuhn  1991]  A  draft  was  balloted  in  July  1992,  and  a  standard  was  expected  mid- 1993. 

5.2.7  OSF/Motif 

The  OSF/Motif  GUI  is  the  result  of  OSFs  request  for  technology  (RFT)  process,  which 
solicited  input  from  the  worldwide  computer  industry  for  GUI  technology.  OSF/Motif  was 
released  in  July  1989  and  incorporates  technologies  from  Digital  Equipment  Corporation,  Hewlett- 
Packard,  and  Microsoft  It  is  currendy  in  Release  1.2. 

OSF/Motif  offers  user-oriented  PC-style  behavior  and  screen  appearance  for  applications 
running  on  any  system  that  can  support  X-Windows  System,  Version  1 1,  Release  5.  It  comprises 
an  API  consisting  of  a  toolkit  and  User  Interface  Language  (UIL).  In  addition,  its  window 
manager  offers  a  standard  environment  for  manipulating  application  windows.  The  OSF/Motif 
environment  provides  Native  Language  Support  (NLS)  consistent  with  the  NLS  solution  proposed 
in  the  X/Open  XPG3.  The  UIL  can  fully  support  display  of  16-bit  and  compound  strings, 
including  all  character  sets  standardized  by  the  X  Consortium,  to  provide  localization  in  Asian  and 
European  languages.  [Ref.  OSF  1990a] 

OSF  has  produced  a  validation  suite  and,  as  of  May  1993,  there  were  nine  certified 
implementations  of  Motif  1.2.  Motif  is  a  candidate  for  X/Open’s  fast-track  process  and  for 
standardization  as  IEEE  1295.1. 

OSF  plans  to  produce  a  significant  new  version  of  Motif  in  1993  or  1994,  has  a  parallel 
project  on  interoperability,  and  is  investigating  a  move  to  a  "next-generation  user  environment," 
called  UEC II,  sometime  after  1995.  A  current  major  concern  is  compatibility  with  Windows, 
since  Motif  is  based  on  the  X-Windows  protocol  and  Windows  is  not  Without  the  ability  to 
integrate  the  two,  the  majority  of  PC  users  have  no  way  to  access  applications  through  Motif 
without  running  an  X  terminal  as  one  application  under  Windows  on  their  PC.  Even  when  doing 
this,  there  is  no  easy  way  to  exchange  information  between  the  two  sets  of  applications.  [Ref. 
OSN  1992c] 

An  April  1993  Department  of  the  Air  Force  Electronic  Systems  Center  (ESQ  Memorandum 
mandates  the  use  of  Motif  Version  1.1  in  conjunction  with  X-Windows  as  the  Graphical  User 
Interface  for  all  new  programs  and  modifications  to  existing  systems.  This  applies  to  command 
center  and  management  information  systems,  not  embedded  systems.  [Ref.  ESC  1993] 
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5.2.8  OPEN  LOOK 

OPEN  LOOK,  jointly  developed  by  Sun  Microsystems  and  AT&T  is  another 
implementation-independent  GUI  specification.  On  first  release,  OPEN  LOOK  could  be 
considered  technologically  more  advanced  than  its  OSF  counterpart.  Motif,  since  it  included  such 
features  as  icon  drag  and  drop  handling  as  an  integral  part  Moreover,  utilities  such  as  file 
manager,  calendar  manager,  and  print  manager  are  more  fully  integrated  in  OPEN  LOOK. 
However,  as  a  result  of  the  recent  Common  Open  Software  Environment  (COSE)  agreement  [Ref. 
OSN  1993f]  between  five  major  UNIX  suppliers,  Sun  agreed  to  support  Motif  as  its  standard  GUI 
and  significantly  reduced  its  efforts  on  the  development  of  an  OPEN  LOOK-based  standard. 
Among  other  COSE  agreements,  the  suppliers  have  agreed  on  a  common  UNIX  "dashboard," 
based  on  Motif  to  pull  the  UNIX  industry  together  and  strengthen  X/Open's  position  as  a  broker  of 
industry  standards.  In  August  1993,  the  working  group  developing  the  OPEN  LOOK  standard 
formally  withdrew,  leaving  Motif  as  the  only  X  based  standard  effort  [Ref.  Hurd  1993] 

5.2.9  Form  Interface  Management  System  (FIMS)22 

The  Form  Interface  Management  System  (FIMS)  is  being  developed  by  SC22/WG18. 
FIMS  (DIS  1 1730)  is  a  high-level  user  interface  tool  that  builds  on  top  of  the  windowing  and  menu 
features  in  GUI  tool  kits,  but  at  a  higher  level  of  abstraction.  The  distinctive  features  that  FIMS 
gives  a  form  are  its  record  level  interface,  validation,  and  built-in  dialog  management  model. 

FIMS  achieves  a  high  degree  of  program/device  independence  by  allowing  a  form  to  be 
customized  for  a  device,  taking  advantage  of  its  special  features,  rather  than  being  limited  to  a  least 
common  denominator.  It  is  possible  to  create  a  form  that  looks  natural  on  block-mode  terminals, 
workstations,  and  laser  printers. 

FIMS  is  optimized  for  operation  in  a  network,  where  the  user  interface  often  sits  on  a  front- 
end  node.  Dialog  management  facilities  allow  efficient  user  interaction.  Since  the  API  is  at  the 
record  level,  network  traffic  is  minimized.  [Ref.  Frantz  1992] 

5.2.10  Extensible  Virtual  Toolkit  (XVT) 

Version  2.0  of  XVT,  available  from  XVT  Software,  Inc.,  was  published  January  1990. 
XVT  allows  applications  to  be  portable  among  various  window  systems  including  Motif,  OPEN 
LOOK,  MS-Windows,  Macintosh,  OS/2  Presentation  Manager,  and  CIOS  Presentation  Manager. 
It  does  not  provide  window  and  graphics  support,  only  a  common  interface  that  applications  can 
use  to  access  the  features  of  the  underlying  window  and  graphics  system.  IEEE  P1201.1  has 
adopted  XVT  and  the  base  document  for  its  work,  and  several  major  software/hardware  vendors 
have  chosen  it  as  the  API  to  be  used  on  UNIX  platforms.  [Ref.  APP  1992] 

5.2.11  Intelligent  HCI 

The  Computer-Human  Object-Oriented  Reasoning  Interface  System  (CHORUS)  is  a 
generic  architecture  for  intelligent  interfaces.  Its  features  include  an  attempt  to  isolate  and 
implement  the  main  functionalities  of  an  intelligent  interface,  multimode  input,  interpretation  of 
user  input  in  terms  of  goals  and  plans,  and  adaptation  of  the  interface  features  to  the  individual 
user.  [Ref.  RNLA  1994,  p.  335] 


22  "The  Standards  Reporter,"  in  Open  Systems  Standards  Tracking  Report,  Volume  1,  No.  1,  October  1991,  p.  2. 
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5.3  HCI  Style  Guidelines 

The  following  documents  have  been  developed  to  provide  guidelines  for  the  use  of  HCI 
standards  and  COTS  products  meeting  such  standards  (civil  standards  are  listed  first): 

•  NIST  User  Interface  System  Reference  Model 

•  FIPS  158,  User  Interface  Component  of  Applications  Portability  Profile,  Version  1, 
May  1990 

•  IEEE  P1201.2,  Recommended  Practices  for  Graphical  User  Interface  Driveability, 
IEEE,  Draft  2,  May  1992 

•  OPEN  LOOK  Graphical  User  Interface  Application  Style  Guidelines;  Sun 
Microsystems,  Inc.,  AT&T,  Second  Printing,  June  1990 

•  OSF/Motif  Style  Guide,  Open  Software  Foundation,  Release  1.0, 1990 

•  Human  Computer  Interface  Style  Guide,  Center  for  Information  Management,  US 
Defense  Information  Systems  Agency,  Version  3.0, 31  July  1993,  UNCLASSIFIED 

•  DoD  Intelligence  Information  Systems  (DODIIS)  Style  Guide,  DODOS  Management 
Board,  June  1991 

•  Air  Force  Intelligence  Data  Handling  System  Style  Guide,  US  Air  Force  Intelligence 
Agency,  October  1990 

•  Defense  Intelligence  Agency  (DIA)  Standard  User  Interface  Style  Guide  for 
Compartmented  Mode  Workstations  (known  as  the  DIA  Style  Guide),  DIA  DIA 
Memorandum  U-15.284/DSE-3,  31  May  1983 

•  ST AN  AG  2019,  Military  Symbols  for  Land-Based  Systems;  Army  Field  Manual  (FM) 
101-5-1,  Operational  Terms  and  Symbols,  October  1985;  and  DIAM  65-xxx,  Standard 
Military  Graphics  Symbols,  Draft,  DIA  1990 

•  Human  Factors  Guidelines  for  the  Army  Tactical  Command  and  Control  System 
Soldier-Machine  Interface,  US  Army  by  Pacific  Northwest  Laboratories, 
August  1990. 

The  US  DoD  HCI  Style  Guide  is  based  on  the  above  documents.  Indeed,  it  is  an 
adaptation  of  the  DoD  Intelligence  Information  Systems  ( DODIIS )  Style  Guide,  and  it  is  based  on 
the  NIST  User  Interface  System  Reference  Model.  It  presents  guidelines  for  application 
development  within  Layers  0  through  5  of  die  Reference  Model  as  follows: 

•  Layer  0  (Data  Stream  Encoding):  Network  Protocol  from  X-Windows 

•  Layers  1  and  2  (Data  Stream  Interface  and  Subroutine  Foundation):  Library  Functions 
from  X-Windows 

•  Layer  3:  Subroutine  Foundation:  Toolkit  standards  that  support  the  window 
management  application  program  interface  (API) 

•  Layers  4  and  5  (Presentation  and  Dialog):  User  Interface  Design  Language  (UIDL) 
and  User  Interface  Management  System  (UIMS) — these  define  the  “look  and  feel”  of 
the  GUI. 

The  purpose  of  an  HCI  style  guide  is  to  provide  a  common  framework  for  HCI  design  and 
implementation.  It  is  to  be  used  to  standardize  interface  implementation  options,  enabling  all 
applications  to  appear  and  operate  in  a  reasonably  consistent  manner.  Specifying  the  appearance, 
operation,  and  behavior  of  software  applications  will  support  such  operational  objectives  as  higher 
productivity,  reduced  training  time,  and  reduced  development  time.  The  emphasis  of  the 
guidelines  is  on  considerations  for  features  and  functions  such  as  system  start-up,  security  issues, 
and  map  graphics. 
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5.4  Assessment 

Of  all  the  service  groups,  standards  for  the  user  interface  services  are  some  of  the  least 
mature.  This  area  suffers  from  a  general  lack  of  standards  for  toolkits  and  UIMS  and  at  the  API 
level  itself.  API  directions  likely  to  be  taken  over  the  next  5-10  years  are  uncertain.  GUIs  remain 
in  the  research  stage.  Standards  for  window  management  are  only  emerging.  While  X-Windows 
still  has  not  reached  the  stage  of  becoming  an  international  standard,  work  is  progressing. 
X- Windows  has  wide  support  in  the  United  States  and  elsewhere,  but  the  implementations  are  not 
standardized.  Moreover,  most  of  the  X-Windows  functionality  is  available  only  at  a  low  level,  too 
low  for  most  application  programming.  The  Extensible  Virtual  Toolkit  (XVT)  is  one  of  many 
toolkits  that  provide  a  higher  level  API  to  window  system  functions  that  are  window-system 
independent  There  are  as  yet  no  standards  for  the  “look  and  feel”  for  application  software  fen-  the 
upper  layers  (Presentation  and  Dialog)  of  the  user  interface  system  reference  model  (see 
Section  5.3).  User  interface  services  may  be  one  area  in  which  de  facto  standards  must  be  used  in 
lieu  of  international  standardization. 
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6.  DATA  MANAGEMENT  SERVICE  STANDARDS 
6.1  Requirements 

Data  management  standards  support  the  storage,  control, 
distribution,  management,  and  allocation  of  simple  data  (text  and 
numeric  information)  as  well  as  complex  data  (complete 
documents,  maps,  charts,  images,  and  multimedia  objects).  An 
overview  of  the  status  of  data  management  service  standards  is 
given  in  Table  5. 

One  or  more  standard  query  languages  can  be  used  as  the 
basis  of  the  peer-to-peer  protocol  for  the  exchange  of  data 
between  information  systems.  More  than  one  type  of  data 
structure  (e.g.,  relational,  hierarchical,  image/map  oriented)  ma> 
be  required.  The  information  transfer  services  are  primarily 
constrained  by  finite  communications  bandwidth  and  security. 

Managing  Data  Complexity.  Enabling  users  to  pull 
information  they  need  in  an  ad  hoc  way  from  diverse  sources 
requires  database  interoperability.  SQL-based  database 
management  systems  are  in  widespread  use  for  this  purpose. 
Future  developments  that  enhance  portability  include 
“transparent  access”  database  exchanges  and  encapsulating 
existing  databases  into  object-oriented  “objectbases.”  [Ref. 
RNLA  1994,  p.  27] 
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Security  and  Exchange  Mechanisms.  Security  is  discussed  in  Section  11.2. 
Exchange  mechanisms  provided  by  the  communications  standards  for  network  services  are 
discussed  in  Chapter  9.  The  data  management  services  will  provide  mechanisms  to  accurately 
represent  the  meanings  and  relationships  of  the  information  items  to  be  managed.  These 
mechanisms  include  the  database  system,  the  conceptual  schema,  and  information  system  domains. 
For  each  type  of  data  structure  to  be  supported,  these  mechanisms  will  provide  a  standard  way  of 
representing  the  data,  including  support  for  common  data  definitions.  (The  definitions  as  well  as 
the  data  would  be  standardized  during  the  implementation  phase  of  a  specific  information  system.) 
An  example  of  one  type  of  support  that  could  be  provided  is  a  data  dictionary  system,  which  could 
be  used  by  information  systems  to  maintain  common  data  definitions  and  representations. 
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Another  example  is  the  data  definition  language  (DDL)  that  may  be  provided  with  a 
database  system  or  language.  The  DDL  must  be  rich  enough  in  its  forms  of  expression  to  have 
attributes  required  of  both  commercial  and  military  systems.  For  example,  it  needs  to  have  the 
capability  to  recognize  several  types  of  hierarchy  for  data  classification  and  compartmentalization 
and  be  trusted  to  permit  access  by  users  with  varying  levels  of  authorization  for  these  classification 
levels  and  compartments. 

6.1.1  Definitions  for  Data  Management  Concepts 

Several  concepts  underlie  data  management  services;  these  may  be  informally  defined  as 
follows.  Persistent  data  are  data  that  are  not  limited  to  a  single  service  request  Metadata  are  data 
about  data,  specifying  the  structure,  format  location,  or  constraints  that  apply  to  data.  A  database 
is  a  collection  of  persistent  data  (which  may  include  metadata  describing  itself  or  other  database) 
managed  in  accordance  with  the  metadata  contained  in  a  schema.  A  schema  is  a  collection  of 
metadata  that  describes  and  constrains  a  database  (a  schema  cannot  be  altered  without  ensuring  that 
appropriate  changes  are  made  to  the  database  that  it  describes).  A  database  controller  is  a 
(standardized)  processor  that  provides  access  to  and  management  of  a  (local)  database  in 
accordance  with  the  (local)  schema  describing  that  database  (Database  Language  SQL  provides 
database  controller  services).  Local  distribution  data  is  a  local  source  of  descriptions  of  remote 
data.  A  distribution  controller  is  a  (standardized)  processor  that  provides  access  to  and 
management  of  both  local  and  remote  data  and  metadata.  (Formal  definitions  are  provided  in  the 
Reference  Model  for  Data  Management,  ISQ/IEC  10032).  [Ref.  SC21/WG3  N  1557  Rev  1993] 

6.1.2  Information  System  Requirements  for  Data  Management 

The  following  operational  requirements  for  support  of  data  management  for  information 
systems  have  been  identified  by  ISO/IEC  10032,  Reference  Model  on  Data  Management  (RMDM): 

•  Access  control 

•  Information  systems  life  cycle  support 

•  Configuration  management,  version  control,  and  variants 

•  Concurrent  processing 

•  Database  transaction  management 

•  Performance  engineering 

•  Referencing  data 

•  Extensible  data  modelling  facilities 

•  Support  for  different  data  modelling  facilities  at  the  user  interface 

•  Audit  trails 

•  Recovery 

•  Logical  data  restructuring 

•  Physical  storage  reorganization. 

6.1.3  Partitioned,  Partially  Replicated  Database  Capability 

Data  transfer  services  in  future  information  systems  are  expected  to  be  provided  by  a 
Partitioned,  Partially  Replicated  Database  (PPRDB)  capability.  Partitioning  means  that  the  entire 
information  system  database  is  segmented  into  disjoint  parts  that  are  held  at  geographically  separate 
locations.  Some  of  the  parts  of  the  information  system  database  are  copied  or  replicated  at  other 
locations  to  ensure  survivability  or  to  provide  more  rapid  local  access.  A  partitioned,  partially 
replicated  database  provides  sufficient  flexibility  for  efficient  exchange  of  information  in  a  manner 
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that  minimizes  usage  of  communication  by  permitting  either  "push"  access  (for  updates)  or  "pull" 
access  (for  queries). 

6.1.4  Conceptual  Schema 

A  common  conceptual  schema  is  needed  to  define  all  information  system  data  related  to 
information  exchange.  The  information  system  database  will  be  segmented  or  partitioned  into 
replication  domains,  each  owned  and  managed  by  a  specified  subfunctional  area.  Each  replication 
domain  has  one  master  copy  and  may  have  other  copies  referred  to  as  slave  copies.  A  single 
component  would  be  able  to  access  some,  but  not  all,  of  the  master  and  replication  domains. 

6.1.5  Domains 

Each  domain  comprises  two  parts.  One  part  (domain  details)  provides  the  characteristics 
and  control  information  for  the  domain.  Examples  of  possible  domain  details  are:  name,  owner, 
home  information  system  component  for  the  master  domain,  list  of  permitted  users,  component 
addresses  for  the  replication  domains,  and  security  classification  parameters.  The  other  part  of  a 
domain  (domain  data)  provides  the  values  of  each  data  item.  The  representations  of  some  features 
of  a  domain,  such  as  data  item  characteristics,  data  relationships,  and  data  dictionaries,  are 
implementation  dependent  and  have  therefore  not  been  specified. 

6.1.6  Distributed  and  Federated  Database  Systems 

Distributed  Database  System.  A  distributed  database  may  be  considered  as  a 
collection  of  data  in  which  an  application  process  accessing  the  data  does  not  require  explicit 
connections  to  the  database  environment  In  particular,  an  application  process  functions  in  such  a 
way  that  does  not  need  to  take  into  account  how  data  are  distributed  or  in  which  database 
environment  data  are  processed.  [Ref.  SC21/WG3  N  1557  Rev  1993] 

Distribution  Controllers.  Distributed  database  environments  may  differ  as  to  the 
extent  of  fragmentation  and  replication  of  data  and  the  scope  of  individual  operations  and 
transactions.  A  distribution  controller  is  introduced  into  distributed  database  systems  to  provide 
the  services  to  support  those  aspects  of  managing  data  in  a  distributed  environment  that  are  not 
provided  by  each  local  environment  [Ref.  SC21/WG3  N  1557  Rev  1993] 

Federated  Database  System.  In  some  cases  of  distributed  database  systems,  there  are 
no  prior  constraints  involving  the  need  to  support  particular  kinds  of  operations  or  interfaces  to 
existing  components.  In  these  cases,  the  capabilities  of  the  distribution  controller  determine  the 
degree  of  management  of  data  that  is  possible.  In  cases  of  design  and  construction  of  an 
information  system  in  which  there  are  a  number  of  pre-existing  database  systems,  an  additional 
design  criterion  is  the  extent  to  which  the  component  database  systems  retain  a  degree  of  autonomy 
for  their  own  operation.  Related  design  choices  include  (1)  decisions  for  each  user  of  an  original 
component  database  system  to  decide  whether  to  continue  to  access  their  data  directly  through  the 
local  database  system  or  through  a  distribution  controller,  and  (2)  deciding  the  scope  of  constraints, 
whether  they  remain  local  to  a  database  environment  or  involve  data  distributed  in  many  database 
environments.  The  general  situation,  in  which  there  is  some  combination  of  component  autonomy 
and  distributed  data  management  is  known  as  a  federated  database  system.  [Ref. 
SC21/WG3  N  1557  Rev  1993] 

Distributed  Access.  A  distributed  information  system  may  include  a  number  of 
autonomous  database  systems  whose  data  are  to  be  shared,  possibly  on  an  at  hoc  basis,  by 
application  processes.  In  this  situation,  cooperative  data  management  is  limited  to  providing  for 
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remote  access  to  data.  The  distribution  controller  can  provide  such  application  processes  with 
services  that  enable  some  degree  of  distributed  processing,  such  as  transactions  encompassing 
multiple  database  environments.  One  particular  requirement  for  the  ad  hoc  use  of  data  is  the  need 
for  access  to  appropriate  data  definitions,  providing  both  a  syntax  (representation)  and  semantics 
(meaning)  of  the  data.  [Ref.  SC21/WG3  N  1557  Rev  1993] 

Distribution  Data,  Distribution  data  describe  the  way  that  data  are  distributed  in  a 
distributed  database  system.  Since  operation  of  a  distributed  database  may  involve  exchange  of 
distribution  data,  a  standard  is  required  for  its  definition.  A  standard  schema  for  distribution  data 
is  needed  that  is  consistent  with  and  supportive  of  the  information  system  requirements  noted  in 
Section  6.1.2  (above)  and  the  special  requirements  for  distributed  information  systems  given 
below.  There  may  also  be  a  need  to  define  a  set  of  standard  services  to  make  use  of  the 
distribution  data. 

Special  Requirements.  Requirements  from  ISO  10032  to  support  data  management  in 
a  distributed  information  system  (in  addition  to  those  identified  in  Section  6.1.2)  are  the  following: 
distribution  control,  database  transaction  management,  communications,  export/import, 
distribution  independence,  system  autonomy,  and  recovery  of  a  distributed  database.  Four 
additional  requirements  are  under  study  in  ISO:  distributed  deadlock  management,  query 
processing,  distributed  query  optimization,  and  heterogeneity  (encompassing  data  modelling 
facilities,  database  management  system  implementations,  and  multiple  schema  representations  and 
interpretations). 

6.1.7  Required  Services 

The  following  basic  services  appear  to  be  required: 

•  Data  definition — provides  a  common  understanding  between  systems  on  the  attributes 
and  meaning  of  data. 

•  Local  queries — queries  that  can  be  satisfied  by  a  data  item  or  a  set  of  items  as  specified 
in  parameters  supplied  in  the  query,  subject  to  authentication  of  the  requestor's  identity 
before  issuing  the  data,  such  that  the  data  resides  in  either  a  master  or  slave  copy  at  the 
location  where  the  query  is  made. 

•  Remote  queries — transfers,  from  a  remote  master  or  slave  copy,  of  a  data  item  or  a  set 
of  items  as  specified  in  parameters  supplied  in  the  query,  subject  to  authentication  of 
the  requestor's  identity  before  issuing  the  data,  from  a  location  other  than  the  one 
where  the  query  originated. 

•  Consistency  control — ensures  that  any  updates  to  values  of  data  items  in  a  slave  copy 
ultimately  become  the  same  as  the  values  in  the  master  copies  of  the  relevant  domain; 
consistency  control  also  ensures  that  update  transactions  are  applied  in  the  correct 
order. 

•  Local  updating — provides  for  changing  the  values  of  a  data  item  or  set  of  data  items 
for  a  domain,  where  the  master  copy  is  held  at  the  same  location  as  the  one  where  the 
update  originated. 

•  Local  slave  updating — provides  for  changing  the  values  of  a  data  item  or  set  of  data 
items  for  a  slave  domain,  but  without  replication  of  the  updates. 

•  Remote  updating — provides  for  changing  the  values  of  a  data  item  or  set  of  data  items 
for  a  domain,  where  the  master  copy  is  at  a  remote  location;  these  operations  are 
subsequently  directed  to  all  slave  copies  of  the  relevant  domain. 

•  Integrity  of  replicas— ensures  that  each  replica,  together  with  deferred  updates,  can  be 
used  to  replace  the  master  domain  in  the  event  of  a  system  failure. 
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•  Management  of  distribution — supports  the  partitioning  and  partial  replication  of  the 
databases. 

•  Recovery  from  failure — provides  mechanisms  to  decide  that  there  has  been  a  failure, 
allows  recovery  from  failure,  and  permits  a  slave  copy  to  become  a  master  copy. 

•  Master-slave  management — permits  a  slave  to  become  the  master  and  new  slave  copies 
to  be  designated  dynamically. 

•  Database  statistics — provides  status  and  usage  data  for  the  system  manager. 

•  Database  initialization — provides  for  the  creation  and  loading  of  initial  values  of  a 
database  and  its  replicas  when  the  system  is  initialized. 

•  Standard  knowledge  base — documents  knowledge  information. 

In  addition,  the  following  management  services  appear  to  be  required: 

•  Create  domain — creates  a  new,  empty  domain,  either  as  a  master  copy  or  for  use  as  a 
replication  copy  of  a  domain. 

•  Delete  domain — deletes  a  domain  and  erases  all  data  in  that  domain.  (When  applied  to 
a  master  copy  it  will  delete  all  associated  replication  copies.) 

•  Transfer  domain— causes,  when  proceeding  to  normal  completion,  the  master  of  the 
domain  to  become  a  slave  copy  and  the  slave  copy  at  a  designated  replication 
component  to  become  the  master. 

•  Assume  domain — provides  for  change  of  ownership  of  a  domain. 

•  Unassume  domain — provides  the  capability  to  resolve  the  situation  in  which  more  than 
one  information  system  component  has  exercised  assumption  of  the  same  domain  by 
designating  another  domain  as  the  master. 

•  Amend  domain — provides  for  changing  the  characteristics  of  a  domain,  such  as  the  list 
of  users  or  the  replication  list,  by  the  owner  or  other  authorized  user. 

•  Details  domain — provides  for  query  of  the  details  or  characteristics  of  a  domain  by  an 
authorized  user. 

•  Copy  domain — copies  the  entire  contents  of  a  domain,  both  characteristics  and  data,  to 
a  replication  copy.  (Space  for  the  copy  is  first  created  by  "create  domain.") 

•  Restore  domain — allows  the  owner  of  a  domain  to  recreate  the  data  in  the  master  copy 
of  the  domain  by  copying  it  from  a  replication  copy,  in  support  of  data  recovery  after 
failure. 

•  Advise  domain — allows  an  information  system  component  to  be  interrogated  to  see  if 
it  holds  a  copy  of  a  domain.  (This  permits  components  who  have  lost  and  then 
reestablished  communications  to  rind  out  whether  the  replication  list  is  correct) 

Some  options  for  standardizing  the  appropriate  features  of  domains  are  inherent  in  the 
discussions  in  the  sections  that  follow.  Some  services  being  evaluated  to  provide  database 
operations  (not  yet  adopted)  imply  implementation  of  a  relational  database  architecture.  Examples 
of  database  operations  are:  select,  update,  delete,  insert,  project,  product,  union,  intersect, 
difference,  divide,  join,  and  equijoin. 

6.2  Standards  for  Database  Services 

This  section  primarily  addresses  the  technical  aspects  of  data  management  The  procedural 
aspects  of  data  management  are  addressed  in  Section  6.3.  The  Reference  Model  for  Data 
Management  described  below  applies  to  both  the  technical  and  procedural  aspects. 
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6.2.1  ISO  Reference  Model  of  Data  Management  (RMDM) 

The  Reference  Model  of  Data  Management  is  ISO  10032.  Development  of  the  RMDM 
began  in  1988,  and  it  was  approved  with  IS  status  in  January  1992. 

ISO  10032  includes  in  the  scope  of  data  management  the  description,  creation, 
modification,  use,  and  control  of  data  in  information  systems.  The  model  provides  a  framework 
for  identifying  interfaces;  positioning  interfaces  relative  to  each  other;  identifying  facilities  provided 
at  each  interface;  identifying  the  process  that  supports  each  interface  and,  where  appropriate,  the 
specific  data  required  for  this  support;  positioning  the  use  of  the  interfaces  in  terms  of  the 
information  system's  life  cycle;  and  identifying  the  binding  alternatives  associated  with  each 
interface.  The  concepts  defined  in  the  model  may  be  used  to  define  the  services  provided  by 
particular  database  management  systems  or  data  dictionary  systems.  The  data  management  field  of 
application  concerns  any  user — human  or  applications  program — who  wants  to  request  services 
for  management  and  storage  of  information  in  a  persistent  manner. 

SC21/WG3  is  preparing  a  technical  report.  Application  of  the  Reference  Model  of  Data 
Management  (formerly  entitled,  Tutorial  for  Reference  Model  of  Data  Management),  that  will 
address  the  following  topics  [Ref.  1ST  21  1534  1988]: 

•  Tutorial  aspects  for  the  Reference  Model  of  Data  Management 

•  Analysis  of  current  database  standards  in  terms  of  the  Reference  Model  concepts 

*  Analysis  of  data  management  services  using  data  flow  diagrams 

*  Description  of  current  database  standards  with  respect  to  the  requirements  of  the 
Reference  Model 

A  rapporteur  meeting  on  the  technical  report  was  held  during  November  to  December  1993.  PDTR 
text  is  expected  in  July  1995,  DTR  in  1996,  and  TR  in  1997. 

6.2.2  Data  Definition  and  Manipulation  Language  Standards 

There  are  now  two  data  manipulation  language  standards  approved  by  ISO:  NDL23  and 
SQL.24  Both  are  standards  of  ANSI  and  are  US  Federal  Information  Processing  Standards 
(FIPS). 

6.2.2. 1  Database  Language  NDL 

Database  Language  NDL  (ISO  8907,  ANSI  X3.133-1986,  FIPS  126)  is  an  outgrowth  of 
1978  Conference  on  Data  Systems  Languages  (CODASYL)  specifications  using  a  network  model 
for  a  DDL  and  a  data  manipulation  language  (DML).  NDL  is  characterized,  in  part,  by  extensive 
use  of  logical  pointers.  These  pointers  support  such  facilities  as  FIND  NEXT  (push  down  in  a 
stack)  and  FIND  OWNER  (pop  up  in  a  stack).  The  specification  work  was  conducted  from  1981 
to  1986  by  the  ANSI  X3H2  Database  Committee.  No  follow-on  standards  activities  are  being 
conducted  by  ISO  or  ANSI  for  NDL.  [Ref.  Deutch  1987;  Gallagher  1988]  Implementations 
supporting  NDL  are  rare.  The  existing  ANSI  and  ISO  NDL  standards  will  likely  be  withdrawn 
unless  some  user  or  vendor  establishes  a  requirement  for  its  continued  existence.  [Ref.  Gallagher 
1991a]  Although  NDL  was  reconfirmed  as  an  international  standard  in  1993,  the  UK  requested 
that  the  matter  be  reconsidered  at  the  Yokohama  Meeting  in  June  1993.  When  SC21/WG3  met  in 


23  NIX.  is  not  an  acronym;  historically,  the  term  derived  Cram  the  concept  of  a  network  data  language. 

24  SQL  is  also  not  an  acronym;  historically,  the  term  derived  from  the  concept  of  a  structured  query  language,  but 
today  represents  much  more. 
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Yokohama  in  June  1993,  it  recommended  that  die  NDL  standard  not  be  withdrawn.  (Ref.  SC21  N 
7764  1993;  SC21 N  8123  1993] 

6. 2. 2. 2  Database  Language  SQL  • 

SQL  (ISO  9075,  ANSI  X3. 135-1986,  FIPS  127)  is  based  on  a  relational  database  model; 
the  specification  work  was  conducted  from  1982  to  1986  by  the  ANSI  X3H2  Database  Committee. 
Future  work  in  the  standards  for  database  management  systems  by  ISO  and  ANSI  X3H2  will  be 
on  distributed  database  processing  (e.g.,  remote  data  access  protocol)  and  extensions  to  SQL.  The 
first  ISO  standard  for  SQL  was  ISO  9075:1988. 

Both  ISO  and  ANSI  worked  closely  together  and  in  parallel  on  a  second  edition  of  SQL 
(known  as  SQL2  during  its  development),  which  achieved  IS  status  in  1992.  This  standard  is  an 
upward  compatible  enhancement  of  two  existing  SQL  standards:  SQL  with  Integrity  Enhancement 
(ANSI  X3. 135- 1989;  ISO  9075:1989)  and  Database  Language  -  Embedded  SQL  for  COBOL, 
FORTRAN,  PL/1,  Ada ,  and  C  (ANSI  X3. 168- 1989).  The  technical  content  of  ISO  9075:1988  is 
retained  as  a  level  of  the  1992  standard.  The  Integrity  Enhancement  Feature  provides  for  check 
clauses,  default  clauses,  and  referential  integrity  constraints.  Two  addenda  to  ISO  9075:1992  are 
in  progress: 

•  WDAD  1,  Addendum  1:  SQL  Call-Level  Interface  (CLI),  Working  Draft,  January 
1993  [SC21  N  7596]  PDAD  status  recommended  by  WG  3. 

•  WDAD  2,  Addendum  2:  Persistent  SQL  Modules,  Working  Draft,  January  1993 
[SC21  N  7597]  PDAD  status  recommended  by  WG  3. 

The  ANSI  standard  X3. 135- 1986  SQL  allows  for  two  levels  of  compliance.  Level  1  is  a 
core  standard  that  leaves  many  areas  open  to  implementation  definition.  Level  2  contains  many 
extensions  over  Level  1,  but  Level  2  still  has  a  large  number  of  options  for  implementation. 
Examples  of  facilities  found  in  Level  2  but  not  in  Level  1  are  [Ref.  Martin  1989]: 

•  Atomic  transactions  with  respect  to  recovery 

•  Eighteen-character  identifiers 

•  Table-name  qualification  by  user-name 

•  Indicator  variables 

•  Outer  references 

•  Keyword  ALL  allowed  in  query-specifications,  sub-queries,  and  set  functions 

•  Updatable  query-specification  definitions 

•  Statements  atomic  with  respect  to  database  changes 

•  Not  equal  to  comparisons  (o) 

•  Escape  characters  in  the  LIKE  predicate 

•  REAL,  DOUBLE  PRECISION,  and  NUMERIC  data  types 

•  WITH  CHECK  OPTION  on  a  view  definition 

•  WITH  GRANT  OPTION  on  a  privilege  definition 

•  DISTINCT  with  AVG,  MAX,  MIN,  and  SUM. 

In  February  1990,  FIPS  127  was  revised  (FIPS  127-1)  to  incorporate  integrity 
enhancement  and  embedded  SQL.  FIPS  127-1  also  documents  guidelines  and  considerations  for 
procuring  SQL  systems.  It  was  revised  again  (FIPS  127-2)  in  February  1992  to  adopt  SQL2. 

NIST  has  established  a  test  suite  and  formal  testing  service  which  provide  a  basic  SQL 
conformance  validation.  The  NIST  SQL  Test  Suite,  Version  4,  July  1993  consists  of  over  450 
tests,  and  NIST  issues  certificates  of  validation.  [Ref.  Sullivan  1992]  The  test  suite  measures 
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conformance  to  required  features  of  FIPS  PUB  127-2.  The  1992  SQL  standard  is  divided  into 
three  bands:  entry  level,  intermediate  level,  and  full.25  The  FIPS  127-2  adds  a  fourth  band: 
transitional.  The  NIST  SQL  Test  Suite  tests  only  the  entry  level.  NIST  anticipates  that  the 
transitional  level  tests  will  be  available  in  1995.26  NIST  publishes  a  quarterly  list  of  FIPS- 
validated  processors.  Validation  summary  reports  (VSR)  are  issued  for  each  test  conducted, 
regardless  of  when  certificates  are  issued.  [Ref.  APP  1992] 

Work  has  already  begun  on  a  third  edition  of  ISO  9075  (known  during  its  development  as 
SQL3).  The  SQL3  working  draft  is  contained  in  SC 21  N  6931,  June  1992,  and  the  statement  and 
content  of  the  project  is  in  SC21  N  8091,  June  1993.  SQL3  is  currently  in  its  4th  working  draft. 
CD  text  is  expected  in  July  1994,  DIS  in  July  1995,  and  IS  in  July  1996.  SQL3  includes  many 
facilities  important  to  engineering  and  scientific  applications,  including  object  data  management, 
hierarchies  of  class  definitions,  inheritance,  complex  types,  user  defined  data  types,  generalized 
triggers  and  assertions,  export/import  of  databases;  and  support  for  database  management  [Ref. 
DRA  1994].  SQL3  would  incorporate  the  following  features: 

•  Generalized  triggers  (similar  to  IF.. .THEN  statements;  based  on  a  condition  of  data, 
not  time) 

•  Generalized  assertions  (given  a  certain  condition,  to  trigger  integrity  checks  on  the 
database  to  be  done  before  and  after  validation  on  values  in  the  database) 

•  Recursive  expressions  (these  allow  an  open-ended  subordinate  assertion,  such  as  to 
completely  search  a  tree;  currently,  only  finite  queries  to  specified  levels  are  permitted) 

•  Escape  from  SQL  to  call  external  features 

•  Basic  capability  for  user-defined  data  types  (the  only  structure  in  SQL  is  a  table;  this 
allows  the  user  to  declare  a  domain  separate  from  a  table) 

•  Support  for  subtables,  provided  through  inheritance  and  generalization  features 

•  Appropriate  support  tools  for  object-oriented  and  knowledge-based  systems. 

An  analysis  of  comments  received  on  the  SQL3  WD  showed  general  agreement  on  a 
requirement  to  restructure.  The  following  structure  was  proposed  by  the  database  language  group 
(DBL)  in  November  1992.  SQL3  would  be  separated  into  an  SQL  family  of  standards  consisting 
of  the  following  [Ref.  SC21/WG3  N  1450  1992]: 

•  A  framework  document  that  describes  the  relationship  and  positioning  of  the  "core" 
and  all  "packages" 

•  A  base  document  that  specifies  the  "core"  and  those  packages  whose  definitions  are 
best  expressed  as  part  of  the  base  document 

•  A  set  of  separate  documents,  one  for  each  package  not  contained  in  the  base  document 

SQL3  has  object-oriented  extensions  that  include  user-defined  abstract  data  types, 

addressing  methods,  object  identifiers,  subtypes  and  inheritance,  polymorphism,  type  templates, 
and  integration  with  existing  facilities.  Base  data  type  in  SQL3  include  fixed-length  and  variable- 
length  character  strings,  fixed-length  and  variable-length  bit  strings,  fixed  and  floating  point 
numerics,  dates,  times,  time  stamps,  intervals,  Booleans,  and  enumerations.  Base  data  types  can 
be  used  in  connection  with  generator  types  to  create  new  data  types.  It  is  expected  that  the 
following  generator  data  types,  known  as  complex  object  support,  will  be  added  to  the  SQL3 


25  "NIST  Certifies  Oracle  7  for  SQL  Conformance,''  by  John  Stein  Monroe,  Federal  Computer  Week,  October  18, 
1993,  p.  30. 

26  Per  telephone  conversation  27  October  1993  with  Joan  Sullivan,  NIST  (301)  975-3258. 

Chapter  6  64  Data  Management 

UNCLASSIFIED 


UNCLASSIFIED 


specification:  List,  Set,  and  Array.  It  is  possible  that  other  generator  data  types,  such  as  those 
specified  in  the  Common  Language-Independent  Data  (CLID)  type  specification  (e.g.,  Choice, 
Record)  will  also  be  added  to  the  SQL3  specification.  [Ref.  SC21  N  8205  1993] 

SQL/MM.  SQL  applications  have  the  requirement  to  use  the  same  abstract  data  types 
across  different  application  areas,  thereby  promoting  interoperability  and  sharing  of  data  and 
encouraging  performance  optimization  over  a  manageable  collection  of  types.  The  multi-part 
standard,  referred  to  as  SQL  Multimedia  and  Application  Packages  (SQL/MM),  would  specify 
packages  of  SQL  abstract  data  types  and  consist  of  1 1  parts:  Framework,  Full  Text,  Still 
Graphics,  Animation,  Still  Image,  Full  Motion  Video,  Audio,  Spatial  (2D  and  3D),  Seismic, 
Music,  and  Mathematical  Structures.  The  SQL/MM  project  plan  is  contained  in  SC21  N  8205, 
September  1993.  Since  the  standard  is  proposed  as  a  "companion”  standard  to  SQL3,  its 
standardization  is  dependent  upon  the  standardization  of  SQL3.  The  target  date  for  the 
Framework,  Full  Text,  Still  Graphics,  and  Still  Image  parts  is  1996.  Other  parts  will  follow  in 
subsequent  years.  [Ref.  SC21  WG3  N  1298  1992;  SC21  N  8205  1993]  Working  drafts  of  the 
first  three  parts  have  been  circulated,  for  which  CDs  are  expected  in  June  1994: 

•  Part  1:  Framework  [SC21/WG3  N 1647,  September  1993] 

•  Part  2:  Full-Text  [SC21/WG3  N  1613,  September  1993] 

•  Part  3:  Spatial  [SC21/WG3  N  1614,  September  1993]. 

The  resource  requirements  necessary  to  forward  this  proposed  new  work  item  to  JTC1  for 
letter  ballot  were  met  in  December  1992.  Since  the  new  work  item  proposal  for  SQL/MM  just  met 
the  criteria  for  acceptance  into  the  JTC1  program  of  work,  SC21  has  been  asked  to  determine  the 
true  level  of  support  and  participation  for  this  work  item.  [Ref.  SC21  N  7744  1993]  Several 
SC18/WG3  activities  on  ODA  are  relevant  to  SQL/MM  work  (see  Section  7.1.1). 

A  working  paper  for  X3H2  [SC21  WG3  N  1286;  ANSI  X3H2-92-8,  November  1991) 
outlines  requirements  for  an  SQL  External  Repository  Interface  so  that  non-SQL  data  repositories 
can  make  their  data  available,  in  simplified  but  standard  form,  to  SQL  systems  or  SQL 
applications. 

A  CALS  (see  Section  7.1.4)  Phase  in  requirement  calls  for  "intelligent"  DBMSs.  SQL3 
intends  to  provide  facilities  for  managing  object-oriented  data  and  for  forming  the  basis  of 
"intelligent"  DBMSs.  Of  particular  importance  are  many  of  the  proposed  SQL3  features  to  the 
STEP  (see  Section  7.2.1)  because  of  that  standard's  unique  data  modelling  and  data  access 
requirements.  Existing  and  planned  features  in  SQL3  may  not  satisfy  all  STEP  requirements,  but 
they  should  provide  an  appropriate  base  from  which  many  requirements  can  be  suitably  addressed. 
[Ref.  Gallagher  1990] 

6. 2. 2. 3  Export/Import  Facilities  for  SQL  and  IRDS 

A  new  work  item  in  SC21,  on  export  and  import  for  SQL  and  IRDS  [SC21  N  5137]  is 
planned  to  be  a  three  part  standard  entitled.  Data  Management  Export/Import  Facilities,  with  three 
parts: 

•  Part  1:  Framework 

•  Part  2:  Facilities  for  SQL 

•  Part  3:  Facilities  for  IRDS. 

The  new  work  item,  Generic  Data  Management  Export/Import,  was  not  accepted.  A  revision 
focused  on  SQL  and  IRDS  was  accepted  in  1991  [JTC1  N  1484]  and  later  restructured 
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(June  1993)  as  a  multi-part  standard.  Although  the  parts  will  be  progressed  separately,  CD  status 
is  expected  in  July  1994,  DIS  in  July  1995,  and  IS  in  July  19%. 

6.2. 2. 4  Common  Language-Independent  Data  Type 

WG3  has  noted  that  the  Common  Language-Independent  Data  Type  (CLID;  ISO  1 1404) 
definition  (see  Section  4.3.1)  of  a  Table  differs  significantly  from  that  of  a  Table  in  SQL.  Since 
SQL  has  been  standardized  by  ISO  since  1986,  and  SQL  tables  are  in  widespread  use,  the  SQL 
concept,  well  founded  in  relational  theory,  appears  to  be  a  strong  candidate  as  a  common  language- 
independent  data  type.  Therefore,  DBL  passed  a  motion  authorizing  a  paper  [SC21/WG3  N  1452] 
defining  the  differences  between  the  existing  SQL  and  CLID  concepts  of  a  table,  be  submitted  to 
SC21/WG3  and  to  SC22/WG1 1  for  the  purpose  of  recommending  that  CLID  either  adopt  the  SQL 
concept  or  drop  Table  from  their  specification.  [Ref.  SC21/WG3  N  1452  1992] 

6. 2. 2. 5  SQL  Ada  Module  Description  Language 

The  SQL  Ada  Module  Description  Language  (SAMeDL)  (CD  12227)  effort  is  the  subject  of 
standardization  by  SC22/WG9.  SAMeDL  is  a  language  which,  when  processed  by  an  appropriate 
tool,  generates  the  SAME  abstract  module  and  other  code  necessary  to  access  a  particular  database 
management  system.  [Ref.  AJPO  1992]  The  standard  is  currently  in  DIS  balloting. 

6.2. 2.6  SQL  Access 

An  historical  problem  with  SQL  has  been  the  creation  of  non-standard  versions  resulting  in 
interoperability  problems,  especially  in  distributed  environments.  In  1989,  several  mid-tier 
database  vendors  recognized  the  problem  and  organized  the  SQL  Access  Group  (SAG)  to  resolve 
some  of  the  SQL  incompatibilities.  SAG  works  on  middleware  (see  Section  13.5.1)  standards  for 
both  accessing  data  and  navigating  networks,  but  progress  has  been  slow.  Vendor  contributions  to 
SAG  include  Microsoft's  Open  Database  Connectivity  (ODBC)27  specification  and  the  Independent 
Database  API  (IDAPI)  by  Borland  International,  IBM,  and  Novell.  [Ref.  Stahl  1993] 

6.2.3  Remote  Data  Access  (RDA) 

Scope  of  RDA.  In  many  environments,  there  are  heterogeneous  database  systems  that 
need  to  be  interconnected.  The  Remote  Database  Access  (RDA)  standard  provides  the 
communication  mechanisms  to  integrate  such  systems.  It  provides  independence  such  that  a  RDA 
user  can  use  the  same  front  end  to  access  different  database  systems,  and  a  single  database  may  be 
shared  by  different  workstations.  RDA  specifies  a  two-way  transfer  syntax  as  well  as  the 
semantics  for  database  operations.  [Ref.  Tang  1992;  IGOSS  1993] 

RDA  addresses  distributed  database  processing  in  a  client-server  environment.  An  RDA 
client,  modelled  by  an  application  process  running  in  some  workstation,  reads  or  updates  a  remote 
database  system.  The  interface  between  a  RDA  client  and  the  RDA  service  provider  can  operate  in 
either  a  synchronous  or  an  asynchronous  mode.  A  RDA  server,  which  is  attached  to  a  database 
system,  responds  to  requests  from  a  RDA  client  Both  the  RDA  client  and  the  RDA  server  are 
RDA  service  users.  [Ref.  Tang  1992] 


27  The  ODBC  specification  allows  developers  of  client  software  to  connect  applications  to  a  variety  of  database 
servers  by  writing  to  one  SQL  application  programming  interface  (API).  [Ref.  OSN  1993m] 
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RDA28  is  an  ISO  standard  to  facilitate  access  to  databases  from  intelligent  workstations  and 
from  other  database  systems.  It  is  essentially  a  (standard)  generalization  of  certain  operations  of 
database  systems,  file  servers,  and  document  servers.  RDA  will  allow,  with  a  minimum  of 
technical  agreement  outside  the  interconnection  standards,  the  interconnection  of  applications  and 
database  systems  from  different  manufacturers,  under  different  managements,  of  different  levels  of 
complexity,  and  exploiting  different  technologies.  Since  an  application  may  itself  be  a  database 
system,  RDA  can  be  used  to  support  multi-database  system  interworking. 

RDA  service  is  designed  to  provide  all  possible  valid  data  manipulation  functions  on  any 
database.  The  functions  needed  (and  available)  depend  on  the  structure  and  content  of  the 
database,  so  the  definition  of  these  functions  must  be  accomplished  at  run  time  (not  explicitly 
coded  into  software).  Thus,  RDA  allows  data  management  language  operations  to  be  defined  and 
named  (actually  numbered),  so  that  they  can  be  repeatedly  invoked  later  in  an  application  and 
association. 

RDA  Standards.  The  ISO  standard  for  RDA  (ISO  9579)  defines  the  format  and 
meaning  of  messages  that  support  this  application.  RDA  uses  the  following  common  application 
service  elements  (ASEs)  to  provide  the  communications  services:  Association  Control  Service 
Element  (ACSE;  ISO  8649  and  ISO  8650);  Commitment  Concurrency  and  Recovery  (CCR; 
ISO  9804  and  ISO  9805);  and  ROSE  (ISO  9072).  RDA  can  be  viewed  as  a  composition  of  ACSE 
and  CCR  with  a  specialization  of  the  ROSE.29  RDA  needs  no  specific  protocol  of  its  own;  it  only 
requires  additional  sequencing  rules  and  a  method  for  handling  violations  of  them.  The  Abstract 
Syntax  Notation  standards  (ISO  8824  and  8825)  are  used  in  the  Presentation  Layer  to  define 
structures  (data  types)  and  rules  for  encoding  structures  so  that  the  structures  can  be  transmitted. 

ISO  9579  is  based  on  work  of  the  ECMA  Technical  Committee  on  Databases,  ITU-TS,  and 
ISO  SCI8.  ECMA  TR30  (December  1985)  was  the  starting  point  for  RDA.  and  ECMA  TR31 
initially  defined  the  concepts,  notation,  and  connection-oriented  mappings  for  remote  operations. 
ISO  9579  has  three  parts  and  several  draft  amendments: 

•  ISO  9579-1  (Part  1):  Generic  Model,  Service,  and  Protocol,  March  1993 
[SC21  N  7689] 

-  WDAM  1,  Amendment  1:  Generic  RDA,  August  1992  [SC21  N  7202]  (PDAM 
expected  June  1993;  DAM  in  June  1994;  AM  in  June  1995]) 

•  ISO  9579-2  (Part  2):  SQL  Specialization,  March  1993  [SC21  N  7703] 

PDAM  1,  Amendment  1:  Support  for  SQL  2,  September  1993  [SC21  N  8307] 
WDAM  2,  Amendment  2:  Support  for  Stored  DBL  Statements,  October  1990 
[SC21  N  5138]  (a  new  work  item  accepted  in  August  1991;  rapporteur  meeting 
January  1994;  PDAM  expected  July  1995) 

•  CD  9579-3  (Part  3):  SQL  PICS  Proforma,  October  1993  [SC21  N  8087]  (formerly 
entitled  IRDS  Specialization)  (editing  meeting  January  1994) 

The  remote  operations  philosophy  is  based  on  object  modelling  in  which  the  functionality 
of  an  object  is  modelled  as  a  set  of  operations  available  at  its  interface.  Object  modelling  also 
includes  the  notion  of  object  classes,  subclasses,  and  property  inheritance.  In  RDA  these  concepts 
are  used  to  define  a  generic  RDA,  which  defines  a  class  of  remote  database  access  applications, 
and  specific  RDAs,  each  of  which  defines  a  subclass  of  RDA  applications.  Those  properties 


28  Discussion  taken  from  Remote  Database  Access  Tutorial,  SC21  N  1927,  28  July  1987;  and  DP  9579-1, 
29  March  1990  [SC21  N  4282]. 

29  Application  service  elements  ACSE,  CCR,  RTSE,  and  ROSE  arc  discussed  in  Section  9.1 1.3. 

Chapter  6  67  Data  Management 

UNCLASSIFIED 


UNCLASSIFIED 


common  to  all  RDA  applications  are  defined  in  the  generic  RDA.  Those  that  relate  to  subclasses 
are  defined  in  RDA  specializations. 

The  generic  RDA  (ISO  9579-1)  can  support  any  data  management  language.  One  of  the 
specific  RDAs  is  a  specification  for  the  Database  Language  SQL.  Other  specific  RDAs  to  be 
developed  in  the  near  future  are  also  expected  to  be  based  on  the  relational  approach.  The  relational 
data  management  language  was  chosen  because  it  supports  complex  selection  functions  and  multi¬ 
record  operations  for  updating  and  deletion.  This  enables  the  RDA  to  accomplish  selection 
processing  in  the  database  server  (the  place  where  the  data  are  stored).  This  reduces  the  amount  of 
unneeded  data  that  are  transferred  to  the  client  (user)  and  thus  minimizes  use  of  communications. 
[Ref.  SC21  N  1927  1987] 

SQL  Specialization  (ISO  9579-2)  defines  the  service  and  protocol  for  access  to  databases 
and  supports  the  data  manipulation  functions  of  SQL-  This  is  done  through  specifying  the  transfer 
syntax  for  specific  data  manipulation  functions,  as  provided  for  in  ISO  9075  for  SQL  database 
systems.  The  elements  of  the  SQL  (or  any  other)  specialization  are  definitions  for  [Ref. 
SC21  N  3342  1989]: 

•  Data  resources  available  as  a  result  of  establishing  a  dialogue  and  any  constraints  on 
opening  and  closing  further  data  resources 

•  Data  structure  of  a  class  of  data  objects  supported 

•  Permissible  classes  of  operations  upon  the  objects 

•  Representation  of  all  operations  in  an  abstract  syntax 

•  Representation  for  data  passed  as  parameters  for  these  operations. 

The  SQL  specialization  for  RDA  (ISO  9579-2)  augments  the  generic  RDA  (ISO  9579-1) 
so  that  the  two  parts  together  define  the  following: 

•  Capabilities  of  an  SQL  database  server  that  supports  dialogues  with  clients 

•  Model  of  dialogues  between  the  SQL  database  server  and  remote  users 

•  Model  of  a  dialogue  between  an  RDA  client  and  an  SQL  server 

•  Abstract  service  interface  for  the  RDA  SQL  ASE  that  models  the  communications 
facilities  supporting  interaction  between  the  SQL  client  and  the  SQL  server 

•  RDA  SQL  ASE  protocol  to  support  the  RDA  SQL  service 

•  Characteristics  of  application  contexts  that  include  the  RDA  SQL  ASE 

•  Application  contexts  that  support  remote  database  access  using  SQL,  specifically  the 
RDA  Basic  Application  Context  and  the  RDA  TP  Application  Context. 

An  RDA  application  may  be  implemented  in  conjunction  with  the  Basic  Application  Context 
or  the  TP  Application  Context.  The  Basic  Application  Context  includes  only  the  ACSE  and 
provides  a  one-phase  commit  protocol.  The  TP  Application  Context  provides  a  two-phase  commit 
that  allows  updates  at  multiple  remote  sites  in  the  same  transaction.  Some  options  for  use  o  the 
Basic  Application  Context  (interoperability  parameters)  are  [Ref.  IGOSS  1993]: 

•  Immediate  execution,  which  immediately  executes  the  database  operation 

•  Stored  execution,  which  permits  optimization  by  allowing  database  operations  to  be 
defined  and  stored  in  the  database  server  and  to  be  executed  one  or  more  times  during 
the  RDA  dialogue  possible  with  different  parameters  for  each  execution 

•  Status,  which  allows  the  status  of  a  database  operation  to  be  queried 

•  Cancel,  which  allows  a  database  operation  to  be  cancelled. 
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Other  RDA  Projects.  In  October  1990,  a  new  work  item  proposed  creating  an 
addendum  to  ISO  9579  entitled,  RDA  Support  for  Stored  DBL  Statements  [SC21  N  6257].  In 
November  1991,  WG3  recommended  approval  for  this  new  work  item  and  it  was  registered  as  a 
PDAM  in  May  1992.  However,  a  May  1992  joint-WG3/RDA  and  WG3/DBL  meeting  voted  not 
to  progress  the  draft  document  in  SC21/WG3  N  1243  to  CD  status.  Most  recently,  in  the  absence 
of  an  Editor  and  Target  dates,  SC21  is  recommending  the  cancellation  of  this  project.  [Ref. 
SC21  N  7728  1993] 

A  PDTR,  Remote  Database  Access  Tutorial  [SC21  N  3343,  January  1989],  was  planned 
for  June  1993;  however,  the  project  has  been  cancelled  [Ref.  SC21  N  8081]. 

The  RDA  Rapporteur  Group  has  reviewed  the  proposed  extensions  for  character  sets  in 
ASN.  1  and  associated  encoding  rules  against  WG3  requirements  and  found  that  they  meet  most  of 
the  requirements  [SC21/WG3  N  1248]. 

The  SQL  Access  Group  (see  Appendix  F,  Section  3.30)  and  X/Open  (see  Appendix  F, 
Section  3.35)  are  working  on  a  joint  RDA  specification. 

A  June  1991  report,  Interim  Report  on  the  Feasibility  of  Profiling  Database  Enquiry 
[IST21  N  2880]  extends  the  scope  of  an  earlier  project  on  RDA  to  database  enquiry  (DBE)  for  all 
user-oriented  database  operations,  which  support  and  control  the  creation,  modification,  and 
retrieval  of  data  in  a  database  and  the  maintenance  of  the  logical  structure  of  the  database.  The 
report  concludes  that  work  should  begin  to  define  profiles  for  DBEs  that  would  cover  user  access 
facilities  and  procedures,  information  presentation,  communication,  transaction  management,  and 
database  management.  Hie  work  would  require  additional  base  standards  (e.g.,  RDA  SQL 
specialization,  user  interface  standards,  and  distributed  database  management  standards)  and 
extensions  to  the  taxonomy  of  TR  10000-2.  Work  on  DBE  is  being  undertaken  by  the  EWOS 
Expert  Group  on  Database  Enquiry. 

Expert  Group  on  Database  Enquiry  (EG-DBE).  In  February  1992,  the  European 
Workshop  for  Open  Systems  (EWOS)  established  an  Expert  Group  (EG)  on  DBE.  The  work 
began  on  two  fronts:  (1)  examination  of  the  profile  taxonomy  defined  in  ISO  TR  10000,  and 
(2)  development  of  the  extensions  necessary  to  accommodate  DBE.  [Ref.  SC21  WG3  N  1345 
1992]  The  objects  of  the  EG-DBE  are  to 

•  Define  a  taxonomy  for  the  development  of  functional  standards  in  the  area  of  database 
enquiry  taking  into  account  the  methodology  given  by  ISO/IEC  TR  10000  and  the 
approaches  described  and  referenced  in  the  report  of  EWOS  PT  014;  a  draft  of  an  RDA 
taxonomy  was  discussed  in  October  1993  and  revised  for  approval  of  the  EG-DBE  in 
January  1994  [EWOS/EG-DBE/93/055]. 

•  Develop  profiles  for  DBE,  together  with  complementary  conformance  testing 
specifications 

•  Establish  user  requirements  and  priorities  for  the  development  of  DBE  profiles;  a  draft 
User  Requirements  for  RDA  was  discussed  in  October  1993 
[EWOS/EG-DBE/93/088]. 

DBE  is  intended  to  be  interpreted  in  a  wide  sense,  encompassing  the  communications 
elements  implied  by  remoteness,  the  DBMS  elements  implied  by  database,  and  also  user  interfaces. 

Tito  formal  initial  work  program  of  EG-DBE  contains  the  following: 

(1)  Development  of  taxonomy  for  DBE  requirements 

(2)  Development  of  profiles  for  access  to  relational  databases 
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(3)  Development  of  profiles  for  access  to  databases  containing  large  structured  objects 
(e.g,,  ODA  documents) 

(4)  Development  of  test  specifications  for  profiles 

(5)  Establishment  of  user  requirements  for  DBE  profiles  and  of  additional  DBE  scenarios. 

In  March  1993,  EWOS  requested  an  S-liaison  between  the  EWOS/EG-DBE  and  ISO/IEC 

JTC1  SC21/WG3.  [Ref.  SC21  N  7651  1993]  In  October  1993,  the  EG-DBE  noted 
[EWOS/TA/93/0425]  widespread  interest  in  Internet  convergence  and  work  in  X/Open  on  RDA 
over  TCP/IP. 

6.2.4  Information  Resource  Dictionary  System  (IRDS)  Standards30 

Stable  IRDS  Standards.  An  IRDS  is  a  system  that  provides  facilities  for  creating, 
maintaining,  and  accessing  an  Information  Resource  Dictionary  (IRD)  and  its  IRD  definition. 
There  are  two  stable  international  standards  for  IRDS: 

•  ISO  10027:1990,  IRDS  Framework,  June  1990 

•  ISO  10728,  IRDS  Services  Interface,  1993  [SC21/WG3  N  1466] 

-  PDAM  1:  C  Language  Binding  [SC21  N  8088,  June  1993] 

WDAM  1:  Ada  Language  Binding,  September  1993  [SC21  N  8203]. 

The  IRDS  Framework  provides  a  common  basis  for  developing  IRDs,  which  are  sharable 
repositories  for  the  definition  of  the  information  resources  relevant  to  all  or  part  of  an  enterprise. 
The  IRDS  Services  Interface  specifies  an  interface  that  gives  any  program  full  access  to  all  IRDS 
services,  through  whatever  external  call  interface  is  provided  by  the  language  in  which  the  program 
is  written. 

Information  resources.  Information  resources  governed  by  an  IRD  may  include: 

•  Data  needed  by  the  enterprise 

•  Computerized  and  possibly  noncomputerized  processes  that  are  available  for 
presenting  and  maintaining  such  data 

•  Available  physical  hardware  environment  on  which  such  data  can  be  represented 

•  Organization  of  human  and  physical  resources  that  can  make  use  of  the  information 

•  Human  resources  responsible  for  generating  that  information. 

The  IRDS  standard  does  not  provide  a  standard  definition  of  all  the  above  kinds  of 
information.  Rather,  it  provides  a  framework  for  defining  such  information  in  which  the 
information  can  be  represented  and  managed.  The  content  of  an  IRD  can  be  compared  with  the 
content  of  a  typical  application  database — an  application  database  contains  data  of  relevance  to  the 
day-to-day  operation  of  an  enterprise.  The  difference  is  that  the  data  are  at  a  higher  level  (metadata 
or  data  about  data)  and  may  include  such  entities  as  data  item  types,  data  files,  computer  programs, 
and  subsystems. 

An  IRDS  is  used  to  control  and  document  an  enterprise's  information  resources. 
ISO  10027,  IRDS  Framework,  defines  a  number  of  concepts  that  are  basic  to  data  management 
A  database  is  a  collection  of  interrelated  data  stored  together  with  controlled  redundancy  according 
to  a  schema  to  serve  one  or  more  applications.  Database  integrity  is  the  consistency  of  a  collection 
of  data  in  a  database.  Export  is  the  function  of  extracting  information  from  an  IRDS  and  packaging 
it  to  an  export/import  file.  Import  is  the  function  of  receiving  data  from  an  export/import  file  into 
an  IRDS.  An  IRD  is  a  part  of  a  repository  managed  by  an  IRDS  in  which  the  information 
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resources  of  an  enterprise  may  be  recorded.  A  value  is  an  abstraction  with  a  single  characteristic 
that  can  be  compared  with  other  values  and  that  may  be  represented  by  an  encoding  of  the  value.  A 
data  modelling  facility  is  a  set  of  data  structuring  rules  and  an  associated  set  of  data  manipulation 
rules.  An  application  schema  is  a  set  of  definitions  that  control  what  may  exist  at  any  time  in  an 
application. 

IRDS  framework,  facilities,  and  interfaces.  The  IRDS  Framework  identifies  the 
lands  of  data,  together  with  the  major  processors  and  their  associated  interfaces,  and  the  broad 
nature  of  the  services  provided  at  each  interface.  Aspects  addressed  by  various  IRDS  standards 
include  programming  language  dependence,  interface  style,  data  modelling  facility  used,  and  data 
interchange  format  Examples  of  processor  interface  styles  are  programmatic  (such  as  a  procedure 
call  interface,  consisting  of  a  sequenced  set  of  parameters  and  associated  binding  rules  for  the 
CALL  statement  in  a  programming  language);  syntax  for  execution  time  interpretation;  and  service 
convention  (a  standard  set  of  programming  language  independent  conventions  specifying 
parameter  lists  and  service  primitives  for  use  in  an  open  systems  environment).  Examples  of 
alternative  styles  for  human  interfaces  are;  panels  (abstract  screen  formats),  concrete  syntax  (such 
as  a  command  language),  and  graphics. 

An  abstract  syntax  is  the  specification  of  a  service  (such  as  for  an  interface  style)  by  using 
notation  rules  that  are  independent  of  the  encoding  techniques  used  to  represent  them.  An  abstract 
syntax  may  be  used  to  define  a  set  of  service®  without  prescribing  any  linguistic  form  to  be  used 
when  each  service  is  initiated  or  invoked.  (See  Section  9.10.1  for  discussion  of  ASN.l.) 

Examples  of  data  modelling  facilities  are  those  based  on  standard  database  languages  such 
as  NDL  or  SQL,  based  on  a  non-standard  database  language,  specific  to  a  standard  programming 
language  (such  as  COBOL  or  PL/1),  specific  to  a  non-language  standard  (such  as  OSI  Directory 
services),  or  which  are  non-standard  data  modelling  facilities  (such  as  entity-relationship 
modelling).  Each  data  modelling  facility  is  an  intrinsically  independent  means  of  representing  data 
and  possibly  the  services  that  may  be  specified  for  such  data. 

Three  types  of  support  can  be  provided  for  a  database  using  international  standards.  One  is 
using  standardized  services  at  an  interface,  in  which  the  contents  of  some  part  of  the  IRD  are 
defined,  together  with  the  services  by  which  those  contents  may  be  accessed  and  manipulated.  The 
second  type  of  support  is  by  standardizing  in  precise  terms  the  content  of  some  part  of  an  IRD 
according  to  some  prescribed  data  modelling  facility.  The  services  that  may  be  performed  on  that 
data  may  or  may  not  be  implicit  in  the  general  data  manipulation  services  associated  with  that  data 
modelling  facility.  The  third  type  of  support  is  the  use  of  a  standard  data  interchange  format, 
designed  to  facilitate  the  interoperability  of  several  real  systems  by  standardizing  the  formats  of  the 
various  kinds  of  messages  sent  from  one  real  system  to  another.  A  data  interchange  format  may  be 
specific  to  an  application. 

IRDS  provides  for  two  types  of  user  interfaces:  a  menu-driven  (panel)  interface  and  a 
command  language  interface.  The  panel  interface  provides  for  a  structured  path  of  screens  (i.e., 
panels)  by  which  an  inexperienced  user  can  execute  IRDS  functions.  The  command  language  may 
be  used  in  either  an  interactive  or  batch  mode. 

IRDS,  including  the  command  language  and  panel  interfaces,  is  specified  in  terms  of 
entities,  relationships,  and  attributes.  The  entities  represent  or  describe  the  concepts  and  data 
objects  about  which  values  are  to  be  stored  in  the  database.  Relationships  are  binary  associations 
between  two  entities  (e.g.,  one  contains  the  other).  Attributes  represent  the  properties  of  an  entity 
or  relationship.  Each  relationship  and  attribute  is  assigned  a  specific  type.  Entities  can  be 
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compared  if  they  have  a  common  attribute  with  a  common  type.  Ordered  sets  of  attributes,  called 
attribute  groups,  are  also  provided  in  IRDS.  The  IRDS  schema  that  defines  and  controls  what  is 
permitted  in  a  data  dictionary  is  also  defined  using  entities,  relationships,  attributes,  and  attribute 
groups.  IRDS  supports  local  and  universal  naming  conventions  through  three  types  of  entity 
names:  access  names  (used  with  the  command  language),  descriptive  names  (e.g.,  from  a  NATO- 
wide  data  dictionary),  and  alternate  names  (e.g.,  aliases  used  for  the  convenience  of  one  or  more 
nations  or  one  or  more  information  system  components).  IRDS  functions  include  adding, 
deleting,  modifying,  and  copying  entities  and  relationships,  in  addition  to  report  writing. 

IRDS  Services  Interface.  The  IRDS  Services  Interface  gives  an  application  program 
full  access  to  all  IRDS  services,  through  whatever  external  call  interface  is  provided  by  the 
language  in  which  the  program  is  written.  The  standard  (ISO/IEC  10728)  defines  the  semantics  of 
this  interface  and  specifies  the  language  bindings  for  Pascal.  IRDS  facilities  are  formally  defined 
with  data  structure  diagrams  and  working  set  diagrams.  Data  structures  are  specified  using  SQL 
(without  constraining  the  implementation  approach).  Services  and  formats  for  service  data 
structures  are  specified,  in  part,  using  Pascal.  Primary  key,  uniqueness,  referential,  and  check 
constraints  are  included  in  each  formal  data  specification  and  illustrated  diagrammatically  (using  a 
“crow’s  feet”  data  modelling  language).  [Ref.  SC21  N  8202  1993] 

IRDS  Standardization  in  ISO  and  ANSI.  The  IRDS  is  a  data  dictionary  standard 
being  developed  in  parallel  by  both  ISO  (JTC1  SC21/WG3)  and  ANSI  (ANSI  X3H4).  The 
standard  is  based  on  the  entity-relationship  model  and  would  be  applicable  to  Database  Language 
NDL  and  Database  Language  SQL. 

ISO  and  ANSI  differ  in  their  approach  to  IRDS  standardization  as  well  as  in  the  technical 
details.  The  communities  have  diverged  over  the  issue  of  whether  relationships  are  permitted  to 
have  attributes  (ANSI)  or  not  (ISO).  The  rationale  for  the  simpler  model  (no  attributes)  is  that  it 
would  fit  more  easily  with  SQL  tables.  The  rationale  for  the  ANSI  position  is  that  a  model 
permitting  attributes,  while  more  complex  and  more  cumbersome,  would  provide  greater 
flexibility.  Further,  many  existing  products  would  be  invalidated  if  no  attributes  were  permitted 
for  the  relationships. 

ANSI  has  developed  three  IRDS  standards:  (1)  an  IRDS  with  a  human  interface  called  a 
Command  Language  and  Panel  Interface  (ANSI  X3.138),  (2)  a  software  interface  to  the  IRDS 
called  the  IRDS  Software  Interface  (ANSI  X3.185),  and  (3)  IRDS  Export-Import  File  Format 
(ANSI  X3.195),  which  supports  schema  and  metadata  interchange  among  IRDS-compliant 
databases,  among  IRDS  and  CASE  tools  with  repositories  or  dictionaries,  and  between  IRDSs  and 
application  programs. 

ANSI  X3.138  was  adopted  by  the  US  Government  as  FIPS-156,  effective  October  1989. 
An  18-month  transition  period  to  allow  industry  to  produce  and  provide  IRDS  products  during 
which  users  could  use  non-conforming  products  ended  in  March  1991.  [Ref.  APP  1991]  While 
commercial  products  have  been  developed,  their  quality  has  not  yet  been  determined  because  a 
conformance  test  suite  is  not  yet  available.  Conformance  tests  are  under  development  [Ref.  APP 
1992]  An  upgrade  to  FIPS-156  is  not  expected  until  1995.  Most  likely  the  revision  will  be 
influenced  strongly  by  object-oriented  data  models  as  well  as  emerging  repository  and  computer- 
assisted  software  engineering  (CASE)  technologies.  [Ref.  Price  1991] 

ISO  began  a  Command  Language  and  Panel  Interface  Standard  (DP  8800),  but  suspended 
the  effort  in  1987  when  the  ISO  and  ANSI  efforts  diverged.  This  project  has  since  been  cancelled. 
[Ref.  SC21  N  8081  1993] 
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The  IRDS  Services  Interface  (ISO  10728)  is  comparable  to  ANSI  IRDS  ATIS  (Atherton 
Tools  Integration  Standard)  Software  Interface  (X3.185)  in  that  it  allows  software  (as  opposed  to 
humans)  to  access  the  IRDS;  however,  the  technical  details  differ. 

Revision  of  ISO  10728.  ISO  10728,  in  combination  with  the  IRDS  Framework 
standard  (ISO  10027),  forms  the  basis  for  the  first  generation  ISO  IRDS  standard  (sometimes 
called  IRDS1).  Even  though  it  only  recently  reached  IS  status,  work  has  already  begun  on  the 
second  generation  IRDS  (IRDS2).  A  NWI  for  IRDS  Extensions  was  introduced  in  October  1990 
[SC21  N  5139].  Although  the  new  work  item  proposal  received  the  required  number  of  approval 
votes  to  qualify  for  acceptance,  several  National  Bodies  submitted  negative  votes  on  the  basis  that  a 
strong  statement  of  requirements  was  lacking.  Therefore,  JTC1  did  not  make  a  formal  project 
assignment  [JTC1  N  1254].  SC21/WG3  responded  with  a  revised  scope  of  work,  and  the  project 
was  added  to  the  JTCl  program  of  work  in  August  1991  [JTC1  N  1486]  under  the  title  Extensions 
to  the  IRDS  Services  Interface. 

WD  text  for  Extensions  to  the  IRDS  Services  Interface  is  SC21  N  8208,  September  1993. 
The  IRDS  group  is  making  rapid  progress  on  this  project  and  is  requesting  permission  to  register  it 
as  a  CD  in  July  1994  (it  will  be  a  second  edition  of  ISQ/XEC 10728).  DIS  is  expected  in  1995,  and 
IS  in  1996.  [Ref.  SC21  N  8123  1993]  It  will  provide  enhanced  facilities  in  the  following  areas: 

•  IRDS  class  hierarchies,  inheritance  of  data  type  and  behavior,  method  registration,  and 
specification  and  method  invocation 

•  IRDS  data  types,  including  abstract  data  types  and  aggregations 

•  IRDS  triggers 

•  IRDS  services  and  data  structures  to  support  configuration  management  tools 

•  Further  operations  on  working  sets  and  their  contents,  including  the  combination  of 
the  contents  of  two  or  more  working  sets  and  possibly  die  division  of  the  contents  of  a 
single  working  set  into  two  or  more  working  sets 

•  Extensions  to  cross-referencing 

•  Extensions  to  versioning 

•  Access  to  large  numbers  of  IRD  objects,  possibly  by  means  of  access  to  multiple  rows 
in  one  service  invocation 

•  Work  on  level  independent  objects  and  services 

•  Improved  handling  of  IRDS  Content  Modules,  their  inter-relationships  and 
interdependencies 

•  Archiving 

•  Handling  of  extended  character  sets 

•  Access  control. 

IRDS  Services  Interface  Extensions  -  Design  Document  [SC21/WG3  N  1283]  is  a 
standing  document  whose  purpose  is  to  record  decisions  made  in  connection  with  IRDS2.  In 
addition,  it  contains  general  principles  that  will  guide  the  work.  [Ref.  SC21/WG3  N  1283  1992] 

Revision  of  ISO  10027.  The  IRDS  Framework  is  also  undergoing  revision.  The  WD 
text  is  SC21  N  8204,  September  1993.  CD  is  expected  in  July  1994.  The  purpose  of  the  revision 
[Ref.  SC21/WG3  N  1406  1992]  is  to: 

•  Align  the  IRDS  Framework  with  the  Reference  Model  of  Data  Management 
(ISO  10032),  which  did  not  achieve  CD  status  until  after  ISO  10027  was  approved. 

•  Align  the  IRDS  Framework  with  the  ongoing  work  in  the  IRDS  Services  Interface 
(ISO  10728),  SQL,  RDA,  and  other  related  standards  activities. 
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•  Ensure  that  the  IRDS  Framework  provides  a  sound  basis  for  positioning  standards 
needed  to  satisfy  the  user  requirements  as  identified  in  the  ANSI  IRDS  Reference 
Model  Draft  Technical  Report  [SC21/WG3  N  1208]. 

While  the  IRDS  Framework  revision  brings  together  two  major  database  standardization 
activities,  it  further  complicates  the  alignment  of  the  ANSI  and  ISO  standards.  Efforts  on  the  part 
of  ANSI  X3H4  (IRDS)  to  seek  reconciliation  with  ISO  have  not  been  successful 
[Ref.  IST/21: 2499  1991].  WD  status  was  achieved  in  July  1993  and  CD  status  is  expected  in 
January  1994.  DIS  is  expected  in  July  1995  and  IS  in  July  19%.  [Ref.  SC21 N  8123  1993] 

IRDS  Overlap  with  PCTE.  SC21  has  noted  the  overlap  between  IRDS  and  the 
Portable  Common  Tool  Environment  (PCTE)  (see  Section  4.3. 2.2)  and  has  invited 
[SC21 N  7192]  ECMA  TC  33  to  submit  requirements  concerning  this  overlap.  SC21  submitted  a 
request  [SC21  N  8103]  to  JTC1  in  June  1993  for  a  fast-track  ballot  of  PCTE  (DIS  13719, 
September  1993).  Coordination  with  SC7  and  SC22  is  required.  SC21  also  requested  informal 
talks  before  proceeding  with  a  DIS  on  a  second  version  of  ISQ/IEC  10728. 

Other  IRDS  Projects.  Other  ISO  projects  related  to  IRDS  include: 

•  IRDS  Design  Support  far  SQL  Applications — CD  text  was  expected  in  June  1992. 
However,  in  the  absence  of  a  WD,  SC21  is  reassessing  the  project.  [Ref. 
SC21  N  7728  1993]  A  rapporteur  meeting  was  held  in  January  1994,  and  a  CD  is 
expected  in  July  1994. 

•  IRDS  Export/Import — CD  text  was  expected  in  July  1993;  however,  this  project  has 
been  cancelled  and  the  work  is  being  reorganized.  [Ref.  SC21  N  8081  1993]  It  is 
now  being  progressed  as  a  three-part  standard  called  Data  Management  Export/Import 
Facilities  [SC21  N  8123  1993]  (see  Section  6.2.2.3). 

•  IRDS  Conceptual  Schema — December  1992  [SC21  N  7486]  (working  document). 

•  Support  for  SQL1  with  Integrity  Enhancement — working  document  scheduled  for 
completion  in  1993. 

•  Guidelines  for  the  Design  of  IRDS  Content  Modules — A  draft  technical  report  that 
defines  data  structures  to  be  supported  by  IRDS  to  meet  the  needs  of  specific  area  and 
provides  an  agreed  approach  to  the  development  of  IRDS  content  modules  by  various 
committees  (e.g.,  SC7,  SC21,  TC184).  At  the  same  time,  TC184  is  moving  slowly 
towards  development  of  an  IRDS  content  standard,  and  SC7  has  a  new  work  item 
proposal  to  develop  models  for  methods.  The  proposal  for  a  new  work  item  in  SC21 
for  the  Guidelines  document  was  accepted  in  April  1993,  and  a  rapporteur  meeting 
was  held  in  January  1994.  PDTR  is  expected  in  July  1994. 

Semantic  Unification  Meta  Model  (SUMM).  SC21/WG3  has  also  noted  that  there 
is  a  growing  industry  requirement  for  investigation  of  a  unification  meta  model  for  the 
representation  and  manipulation  of  the  data  semantics  managed  by  an  information  repository.  In 
November  1991,  WG3  posed  a  question  [SC21  N  6251]  on  the  IRDS  Definition  Level  Content 
Standard  for  Semantic  Unification  Meta  Model  (SUMM).  The  new  question  was  approved  and 
work  began  in  June  1992.  This  requirement  shares  objectives  with  the  conceptual  schema  and 
common  data  modelling  facility  issues  (see  Section  6.2.5).  [Ref.  SC21  N  6251  1991]  WD  text  of 
the  SUMM:  Technical  Approach  [SC21  WG3  N  1360],  Version  0.7-1,  was  published  in 
October  1991. 

A  technical  report  on  SUMM,  Technical  Report  on  the  Semantic  Unification  Meta-Model, 
Volume  1,  Semantic  Unification  of  Static  Models,  October  1992,  was  prepared  by  th* 
Dictionary/Methodology  Committee  of  the  Initial  Graphics  Exchange  Specification  (IGESyProduct 
Definition  Exchange  Specification  (PDES)  Organization  (IPO)  for  ISO/TC184  SC4/WG3  [Ref. 
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SUMM  1992].  IPO  develops  US  contributions  to  the  Standard  for  die  Exchange  of  Product  Model 
Data  (STEP)  being  developed  by  ISO/TCI 84  SC4AVG3.  The  report  establishes  a  technical  basis 
for  addressing  model  integration  problems  that  arise  when  the  following  three  conditions,  normally 
essential  to  integration,  are  not  met:  (1)  using  the  same  modelling  language,  (2)  sharing  a  common 
culture  of  experience  and  background,  and  (3)  having  a  single  agreed  methodology  to  guide  the 
work.  SUMM  is  a  model  of  the  semantic  structure  of  formal  languages  and  of  the  semantic 
similarities  between  those  languages.  The  original  work  on  SUMM  was  motivated  by  the  need  to 
accurately  translate  an  information  model  (often  called  a  data  model)  written  in  one  formal  language 
into  an  equivalent  model  stated  in  a  different  language,  based  upon  common  underlying  principles. 
An  example  would  be  the  conversion  of  an  model  defined  by  Nijssen  Information  Analysis  Method 
(N1AM)  into  Integrated  Computer-Aided  Manufacturing  (ICAM)  Definition  Language  Type  1 
Extended  (IDEF1X).  [Ref.  SC21/WG3  N  1644  1993] 

Remote  IRDS  Access.  WG3  has  also  noted  a  growing  industry  need  for 
interoperability.  In  the  IRDS  context,  CASE  tools  on  workstations  need  to  access  dictionaries  on 
servers.  Therefore,  WG3  recommended  that  SC  21  ask  JTC1  to  initiate  a  ballot  for  the  registration 
of  a  question  (Q3/009)  on  the  Approach  to  Remote  IRDS  Access.  [Ref.  SC21  N  6253  1991] 
JTCl  authorized  work  to  begin  in  June  1992.  The  question  has  eight  parts,  reproduced  below 
with  the  draft  answers  in  italics  [Ref.  SC21  N  7 181  1992]: 

1 .  What  are  the  requirements  for  the  access  by  a  client  application  in  one  real  system  to 
IRDS  Services,  as  defined  in  ISO  10728  IRDS  Services  Interface,  provided  by  a 
server  in  a  different  real  system?  The  requirement  is  for  applications  such  as  CASE 
tools  to  be  able  to  use  IRDS  services  to  access  IRDS  data  in  a  local  IRDS  (in  the  same 
real  system),  in  a  work  group  IRDS  (in  another  autonomous  real  system),  or  in  a 
corporate  IRDS  (in  another  real  system  to  which  the  local  system  is  to  some  extent 
subservient). 

2.  What  facilities  are  required  to  be  standardized?  A  mechanism  far  communicating 
IRDS  service  requests  and  responses  between  two  real  systems. 

3.  In  what  way  or  ways  should  ISO  standardize  access  by  a  client  application  in  one  real 
system  to  IRDS  Services  provided  by  a  server  in  a  different  real  system?  At  least  by 
an  IRDS  Specialization  of  Remote  Database  Access,  based  on  the  SQL  Specialization 
ofRDA  (ISO  9579-2). 

4.  Should  the  proposed  Standard  be  consistent  with: 

a.  ISO/IEC  10027:  IRDS  Framework 

b.  ISO  9579-1:  Remote  Database  Access  -  Generic 

c.  ISO  9579-2:  Remote  Database  Access  -  SQL  Specialization 

d.  ISO  10728:  IRDS  Services  Interface 

Yes,  with  all  of  these  as  far  as  possible,  though  the  differences  between  IRDS  and 
SQL  will  necessitate  some  differences  from  ISO  9579-2. 

5.  Should  the  proposed  standard  define  a  specialization  of  the  generic  RDA  protocol  or 
should  it  provide  the  required  facilities  by  some  other  means?  To  minimize  the  work 
involved  while  meeting  the  identified  requirements,  the  standard  should  build  on 
existing  work  by  defining  a  specialization  of  die  Generic  RDA  protocol,  based  where 
possible  on  the  existing  SQL  Specialization  ofRDA. 

6.  Should  this  specialization  support  the  access  to  IRD  Definition  level  and  IRD  level  data 
by  means  of  the  invocation,  by  a  client  in  one  real  system,  of  the  services  specified  by 
ISO  10728  IRDS  Services  Interface,  provided  by  a  server  at  a  different  real  system? 
Yes. 
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7.  Should  the  notations  and  mechanisms  used  to  prescribe  die  Remote  IRDS  Services 
protocol  be  those  used  in  ISO  9579-1  (Remote  Database  Access  *  Generic)!  Yes. 

8.  Should  the  design  of  die  protocol  be  restricted  to  being  as  close  as  possible  to  that 
defined  in  the  SQL  specialization  of  RDA  specified  in  DIS  9579-2?  Not  restricted, 
although  die  SQL  specialization  of  RDA  is  likely  to  form  the  starting  point 

Although  a  NWI  request  for  Remote  IRDS  Access  [SC21  WG3  N  1384]  had  been 
proposed,  it  was  dropped  until  consensus  on  the  answer  to  the  above  questions  could  be  obtained. 

An  IRDS  Content  Module  is  a  set  of  definitions  prepared  for  use  with  an  IRDS.  Content 
modules  may  be  defined  by  methods  developers  as  a  precursor  to  building  CASE  tools  to  support 
their  methods,  by  language  developers  requiring  IRDS  support  for  a  programming  language,  by 
DBMS  developers  wishing  IRDS  support  for  their  DBMS,  and  by  many  other  classes  of  potential 
IRDS  users.  The  ISO  IRDS  Rapporteur  Group  has  drafted  a  standing  document  on  Guidelines  for 
the  Design  of  IRDS  Content  Modules  [Ref.  SC21/WG3  N  1272  1991],  and  the  project  has  been 
accepted  into  the  JT Cl  program  of  work.  [Ref.  SC21  N  7742  1993] 

Experts  representing  CASE  Data  Interchange  Format  (CDIF),  IEEE  PI  175  (Reference 
Model  for  Computing  System  Tool  Interconnections ),  and  Product  Definition  Exchange 
Specification  (PDES)  are  working  to  develop  an  IRDS  Content  Module  Standard  for  Software 
Engineering  to  support  the  data  flow  modelling  subject  area.  [Ref.  SC21  WG3  N  1279  1991]  In 
June  1992,  the  SC21  Plenary  accepted  a  new  work  item  proposal  for  a  Technical  Report 
[SC21 N  7178]  entitled  Guidelines  for  die  Design  of  IRDS  Content  Modules  for  ballot  by  SC21. 
The  target  dates  were  WD  in  June  1993,  CD  in  June  1994,  DIS  in  June  1995,  and  IS  in  June 
1996.  [Ref.  SC21  N  7178  1992] 

IRDS  Export/Import  File  Format,  became  an  ANSI  standard  (X3. 195-1991)  in  1991. 
Support  for  Naming  Convention  Validation  (NCV)  was  approved  in  1992  as  X3/TR-1 1.  Several 
other  ANSI  IRDS  efforts  are  nearing  US  public  review  status  while  one  has  been  completed  and 
another  new  work  area  has  been  initiated  [Ref.  Winkler  1991]: 

•  Technical  Report  on  the  IRDS  Reference  Model.  This  report  will  explain  the 
relationship  of  the  IRDS  within  the  information  environment  of  an  enterprise. 

•  Technical  Report  on  Requirements  for  an  IRDS  in  a  Distributed  Heterogeneous 
Environment  This  document,  under  development  by  X3H4.5,  is  progressing  slowly. 

•  Technical  Report  on  Integration  of  IRDS  Schema.  This  report  is  currently  inactive. 
Instead,  X3H4.6  is  wotking  on  a  Technical  Report  on  Model  Unification  for  Data 
Repositories,  which  will  address  the  same  problem  but  at  a  different  level.  The 
technical  report  will  address  the  needs  of  IRDS  users  to  translate,  integrate,  reference, 
and/or  use  differing  models  or  representations  of  enterprise  information  and  behavior 
at  various  levels  of  complexity  and  abstraction.  It  will  establish  a  framework  for  the 
analysis  of  models;  analyze  models;  define  the  IRDS  neutral  unification  model  and  its 
representation;  reconstruct  models  using  the  unification  model;  develop  an  IRDS  meta¬ 
schema;  develop  IRDS  requirements;  develop  IRDS  conceptual  model  architecture 
guidelines;  and  develop  a  test  case.  The  original  target  date  was  January  1993. 

•  Standard  on  Export/Import  Extensions.  ANSI  X3H4  cannot  progress  this  standard 
until  the  Technical  Report  on  Model  Unification  for  Data  Repositories  is  complete. 

•  Technical  Report  for  IRDS  Administration  and  Control  was  expected  in  1993. 

ANSI  X3  recently  announced  a  development  project  for  IRDS  Extensions  to  Support 

CASE  Environment  for  Information  Interchange.  This  standard  would  define  an  IRDS,  based  on 
ANSI  X3.138-1988,  capable  of  supporting  the  full  range  of  IRDS  applications.  In  particular,  it 
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would  be  capable  of  acting  as  the  IRD  in  a  traditional  data  processing  environment  and  capable  of 
providing  the  stable  store  necessary  to  support  an  integrated  CASE  environment.  The  standard 
would  include  both  the  semantics  of  the  IRDS  and  a  software  interface  suitable  to  the  needs  of 
active  CASE  and  Dictionary  tools.  Hie  development  has  been  assigned  to  Technical  Committee 
ANSI  X3H4.2.  [Ref.  CSI 1990] 

IRDS  Services  Architecture  Technical  Report ,  January  1993  [Ref.  IRDS  1993],  is  an 
ANSI  X3H4.1  working  paper  that  will  become  Part  Five  of  the  full  set  of  documents  titled 
"Fritmework  for  the  Evolution  of  IRDS  Standards."  Taken  collectively,  these  documents  are 
intended  to  provide  a  picture  of  the  full  strategic  scope  of  IRDS  systems  as  it  is  currently 
understood.  The  structure  of  the  Framework  for  the  Evolution  of  IRDS  Standards  is  outlined  in 
Table  6. 


Table  6.  Structure  ot  the  Framework  for  the  Evolution  of  IRDS  Standards 


1  p«'< 

Titla 

Purpoaa 

LQLZHH 

Define  IRDS  standardization  strategy 

mim 

Detail  the  program  of  work  with  deliverables,  schedules  and 
responsibility  for  task  execution 

IkTilHT 

Illustrate  scenarios  of  IRDS  use  within  an  enterprise 

Part  Four 

liUggiiMriiSjl 

Establish  IRDS  universe  of  discourse  within  the  context  of  the 
enterprise's  information  system  environment 

Part  ftvo 

Define  architecture  for  organizing  IRDS  services  and 
interface  mechanisms 

Specify  usage  and  system  requirements  to  guide 
development  of  IRDS  standards 

F-*JTTT  fTT1-'  ITT :  < 

iH 

Evolving  the  IRDS  Information 
Modal 

Specify  the  press  for  evolving  the  integrating  application 
content  modules 

Document  functions  and  procedures  needed  to  administer  an 
IRDS  environment 

Part  Tan 

Explain  harmonization  strategy  and  the  relationships  of  IRDS 
models,  architectures  and  standards  to  related  efforts 

LI 

Present  specialized  definitions  for  IRDS  terminology 

EgrigMhTmT 

DS  1983] 

6.2.5  Conceptual  Data  Modelling  Facility  Standards 
6.2. 5.1  Conceptual  Schema 

SC21/WG3  has  identified  five  different  uses  of  the  term  "conceptual  schema."  The 
following  identifies  the  five  uses  and  provides  WG3  comments  on  those  uses  [Ref.  SC21  N  4195 
1990]: 

•  The  results  of  an  analysis  of  the  data  and  possibly  the  processes  perceivable  in  some 
real-world  situation. 

There  is  considerable  disparity  among  the  data  analysis  techniques  used  in  various 
parts  of  die  world.  Some  are  being  energetically  promoted  by  minority  groups. 
There  are  rapid  developments  in  CASE. 

Attempts  to  standardize  on  any  one  technique  may  be  premature.  Such  efforts 
should  await  availability  of  the  Reference  Model  on  Information  Systems 
Engineering  being  developed  by  SC7/WG4. 

-  Work  on  a  conceptual  data  modelling  facility  should  be  considered  as  content  of 
an  IRDS  and  be  conducted  in  accordance  with  the  IRDS  Framework 
(ISO  10027). 
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•  A  repository  of  "metadata”  in  which  it  is  possible  to  specify  declared vely  100%  of  the 
semantics  of  the  data  in  a  computerized  information  system  (the  100%  principle  of 
TR9007).  The  "100%  principle"  now  adopted  by  ISO  [Ref.  SC21  N  197  1982; 
SC21  N  236  1985]  says: 

All  relevant  static  and  dynamic  rules,  law,  etc.,  about  the  universe  of 
discourse  should  be  described  in  the  conceptual  schema.  The 
information  system  cannot  be  held  responsible  for  enforcing  those  rules 
described  elsewhere,  particularly  those  described  in  user  procedures. 

The  100%  principle  has  had  major  influence  on  SC21/WG3  work  in  the 
development  of  SQL.  The  SQL  draft  proposal  being  progressed  contains 
language  specifications  that  make  it  possible  to  specify  declaratively  a  very  large 
percentage  of  the  constraints  on  the  data  that  a  database  designer  is  ever  likely  to 
want  to  define. 

While  SQL  is  never  promoted  as  a  means  of  defining  a  conceptual  schema,  it  is, 
in  this  very  important  respect,  superior  to  many  of  the  approaches  developed 
especially  for  the  purpose. 

•  A  data  definition  that  has  the  property  of  being  independent  of  its  representation  in 
storage. 

Some  standards  committees  have  adopted  the  term  to  refer  to  some  kind  of 
representation  of  the  data  definition  that  is  above  the  level  of  stored 
representations. 

SQL  is  a  language  that  enables  the  preparation  of  a  storage  independent  definition 
of  data. 

•  A  data  definition  that  is  common  to  the  collections  of  data  at  two  separate  sites,  such 
that  it  can  be  used  as  a  common  frame  of  reference  when  exporting  data  from  one  site 
and  importing  it  at  another  site. 

In  EDI,  one  needs  a  definition  of  data  to  be  interchanged  that  is  common  to  all 
sites  involved  in  a  set  of  interchanges. 

Much  of  the  EDI  work  has  been  concerned  with  the  specification  of  standard 
formats  for  an  industry  area,  such  as  banking  or  travel.  As  EDI  tends  to  adopt  a 
more  generalized  approach  to  standardization,  the  need  for  a  common  definition 
facility  becomes  apparent. 

•  A  data  modelling  facility  (see  ISO  10032,  the  Reference  Model  on  Data  Management) 
that  is  different  from  and  therefore  "neutral"  with  respect  to  broadly  similar  data 
modelling  facilities  used  in  commercially  available  database  management  systems. 

Data  modelling  facilities  are  also  called  data  models;  merits  of  various  approaches 
are  controversial  topics. 

Another  "neutral"  approach  would  lead  to  confusion,  is  not  required,  and  is  not 
recommended  by  WG3. 

6. 2. 5. 2  Conceptual  Schema  Standardization 

Work  in  the  area  of  conceptual  schema  in  ISO  dates  back  to  the  early  1980s.  In  1982, 
TC97/SC5  first  published  what  is  now  TR  9007,  Concepts  and  Terminology  for  the  Conceptual 
Schema  and  the  Information  Base.  This  report  was  followed  in  1985  by  the  Assessment 
Guidelines  for  Conceptual  Schema  Language  Proposals. 

SC21  held  a  workshop  on  conceptual  schema  and  its  relationship  to  the  Conceptual  Data 
Modeling  Facility  in  the  Netherlands  in  November  1990.  A  subsequent  workshop  was  held  in 
Anaheim,  California,  in  January  1991  where  papers  on  some  18  different  modelling  methods  were 
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presented.  Two  of  the  approaches  presented  included  the  ANSI  IRDS  approach  and  the  ANSI 
X3.T2  Registering  of  Conceptual  Schemas  approach.  [Ref.  Perez  1991] 

ANSI  has  proposed  that  a  new  question  be  established  in  SC21  to  determine  the  use, 
scope,  and  purpose  of  one  or  more  standards  for  conceptual  schema.  The  goal  would  be  to 
address  the  need  for  models  of  a  "universe  of  discourse  (UOD)."  Such  models  are  needed  to 
clarify  in  a  formal  way  the  notion  of  a  particular  universe  of  discourse  to  which  a  standard  applies 
(e.g.,  for  Directory  schema)  and  to  facilitate  the  specification  of  a  common  universe  of  discourse 
for  information  exchange  (e.g.,  for  Application  Layer  Structure,  ISO  9545).  [Ref.  SC21  N  4511 
1990]  Actions  of  such  an  international  standards  activity  might  include:  (1)  developing  and 
maintaining  a  list  of  approved  answers  and  comments  on  issues  related  the  topic  of  conceptual 
schemas;  (2)  registration;  and  (3)  developing  and  maintaining  one  or  more  standards  for  specifying 
inter-application  information  requirements,  semantics,  concepts,  and  terminology  for  open 
applications.  [Ref.  SC21  N  5851  1991] 

The  United  States  is  developing  a  national  standard  for  conceptual  schema  based  on  the 
Integrated  Computer-Aided  Manufacturing  (ICAM)  Definition  (IDEF)  graphical  methods  for 
defining  the  functions,  data  structures,  and  dynamics  of  manufacturing  businesses,  the  result  of 
US  Air  Force  studies  in  the  late  1970s.  The  data  modelling  language  IDEF1X,  developed  by 
Hughes  Aircraft  and  the  D.  Appleton  Company,  provides  an  entity-attribute-relationship  conceptual 
schema  for  specifying  data  requirements  and  improving  the  quality  of  database  designs.  [Ref. 
Bruce  1992] 

A  US  standard  has  been  issued:  FIPS  184,  Integration  Definition  for  Information 
Modeling  (IDEF1X),  National  Institute  for  Science  and  Technology,  1993.  It  has  an  effective  date 
of  30  June  1994. 

As  noted  in  Section  6.3.1  below,  entity-attribute-relationship  data  models  are  now  being 
required  in  the  US  DoD  for  the  basis  of  future  data  standardization.  IDEF1X  has  been  adopted  as 
the  standard  for  presenting  data  models.  IDEF1X  was  used  to  develop  the  Army  Data  Model 
(which  defines  data  at  the  Army  Staff  level),  the  Battlefield  Generic  Hub  [Ref.  ATCCIS  WP  5-2 
1992]  and  the  Fire  Support  Data  Model  [Ref.  ATCCIS  WP  5-2B  1992]  (IDEF IX  data  models 
have  also  been  developed  in  ATCCIS  for  engineer,  personnel,  and  communications-electronics). 
The  Data  Management  Directorate  of  the  US  Army  Information  Systems  Engineering  Command 
developed  the  Army  Data  Model  and  is  actively  working  on  others.  These  and  25  additional 
projects  have  been  identified  [Ref.  DISA/CIM  1992]  by  DISA/CIM  in  the  area  of  business  process 
improvement,  all  of  which  will  eventually  require  data  modelling. 

ANSI  X3T2  Data  Interchange  Committee  has  a  domestic  standardization  project  entitled, 
"Conceptual  Schema  Specification  for  Data  Interchange."  The  purpose  of  the  project  is  to  define  a 
model,  technique,  and  language  for  specifying  formal  and  informal  conceptual  schemas.  The 
scope  of  the  project  is  to  standardize  a  declarative  technique  for  specifying  and  structuring 
information  semantics  in  a  form  independent  of,  and  compatible  with,  three  ISO  information 
standardization  environments:  (1)  communications,  (2)  processing  and  display,  and  (3)  databases 
and  storage.  The  base  standard  for  this  standard  will  be  TR  9007,  July  1987. 

In  April  1993,  X3T2  issued  a  request  for  early  review  and  comment  on  this  project 
Specifically,  it  has  identified  a  technique  and  language  that  appears  to  meet  a  significant  portion  of 
the  functional  requirements  for  the  proposed  standard.  This  is  the  Knowledge  Interchange  Format 
(KIF)  [SC21/WG3  N  1645]  by  the  Interlingua  Working  Group  of  the  DARPA  Knowledge 
Sharing  Effort  The  document  [Ref.  Genesereth  1992]  is  in  Version  3.0.  [Ref.  X3T2/93-048 
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1993]  KIF  is  a  formal  language  for  the  interchange  of  knowledge  among  disparate  computer 
programs  (e.g.,  written  by  different  programmers  at  different  times  in  different  languages).  The 
specification  includes  declarative  semantics  with  expression  of  arbitrary  sentences  in  predicate 
calculus  and  representation  of  knowledge  about  the  representation  of  knowledge.  [Ref. 
SC21/WG3N 1645  1993] 

6. 2. 5. 3  Conceptual  Data  Modelling  Facility  Standardization 

Japan  proposed  a  new  work  item  in  SC21/WG3  for  a  conceptual  data  modelling  facility 
[SC21  N  4280,  February  1990].  The  proposed  standard  would  specify  the  facility  to  describe  an 
application  data  model  and  the  representation  method  of  the  result  of  the  description  of  an 
application  data  model.  A  Special  Meeting  on  Conceptual  Schema  and  Common  Data  Modelling 
Facilities  was  held  in  Renesse,  Holland,  March  1992.  It  addressed  the  following  issues  [Ref. 
SC21N  6449  1991]: 

•  Requirements  of  various  international  standards  groups  using  the  concepts  and 
terminology  of  conceptual  schemata 

•  Interfaces  and  mechanisms  employed  to  model,  specify,  use,  and  relate  conceptual 
schemas  in  these  activities 

•  Identification  of  the  standardization  groups  now  using,  or  planning  to  use,  conceptual 
schema  techniques  or  common  data  modelling  facilities 

•  Relation  of  the  requirements  and  uses  identified  above 

•  Identification  of  activities  for  the  standardization  of  conceptual  schema  techniques  or 
common  data  modelling  facilities  and  interfaces  to  them  being  undertaken  by  National 
Bodies  or  by  other  standards  organizations 

•  Planning  and  organization  of  future  work  on  conceptual  schemas 

•  Consideration  of  whether  and  how  a  conceptual  schema  can  be  stored  and 
interchanged  using  standard  database  languages 

•  Addressing  the  short-term  considerations  of  coordination  amongst  the  various 
standardization  groups  within  JTC1 

•  Relationship  of  proposals  made  to  existing  standardization  activities  in  the  area  of 
reference  models  and  frameworks. 

The  output  of  the  meeting  consisted  of  recommendations  for  six  new  JTC1  projects  [Ref. 
SC21 N  6945  1992]: 

•  A  question  on  "the  use  of  Standardized  Conceptual  Schema  and  Data  Modelling 
Facilities  in  the  definition  of  JTC1  and  other  ISO  standards” 

•  Development  of  a  Standard  Lexicon  of  Conceptual  Schema  Concepts 

•  Preparation  of  a  technical  report  entitled  A  Framework  for  Model  Comparison 
Transformation  and  Integration 

•  Development  of  a  standard  for  a  Conceptual  Schema  Facility 

•  Preparation  of  a  technical  report  entitled  A  Case  Study  on  die  Harmonization  of 
Standards  Models  in  the  Areas  of  Information  Technology  and  IT  Application 

•  Development  of  a  standard  for  An  Architecture  for  Supporting  Conceptual  Schema 
Facilities. 

Recognizing  the  severity  of  the  problem,  the  SC21  Secretariat  called  a  tutorial  session  in 
May  1992,  during  its  Plenary  to  discuss  data  modelling  facilities,  including  major  results  from  the 
Renesse  workshop.  SC21  requested  that  WG3,  WG4,  WG6,  and  WG7  discuss  and  do 
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preliminary  work  on  the  following  issues  at  their  meetings  in  Ottawa  in  May  1992  [Ref. 
SC21  N  6614  1991]: 

•  Relationship  between  WG3  database  standards  and  data  modelling  facilities  relating  to 
die  Management  Information  Base  of  WG4  OSI  Management  standards 

•  Relationship  between  WG3  database  standards  and  the  data  modelling  facilities 
supported  by  WG4  Directory  Services  standards 

•  Relationship  between  the  data  modelling  support  facilities  of  WG3  and  the  information 
viewpoint  concerns  in  the  Reference  Model  of  ODP 

•  Relationship  between  the  Remote  Database  Access  server  format  supported  by  the 
WG3  work  and  the  ASN.l  extensions  being  developed  by  WG6  (e.g.,  support  of 
tabular  data);  and  the  relationship  between  the  ASN.l  and  its  extensions  and  the 
facilities  for  the  description  for  data  definition  within  an  SQL  database. 

Also  at  its  Plenary  in  May  1992,  SC21  formed  a  Special  Working  Group  (SWG)  for  a 
Study  Period  on  the  topic  of  Modelling  Facilities  (MF)  applying  the  procedures  for  the  preparation 
of  large  new  work  item  proposals.  The  SWG-MF  considered  three  topics  [Ref.  SC21  N  7208 
1992;  DRA  1994]: 

•  Use  of  a  standard  data  modelling  facility  in  defining  standards 

•  Requirement  for  a  standard  conceptual  schema  facility 

•  Inter-relationships  between  such  a  conceptual  schema  facility  and  the  use  of  a 
standard. 

One  product  of  the  SWG-MF  is  the  Proposed  Working  Draft  for  Base  Document  for  Conceptual 
Schema  Modelling  Facilities ,  October  1992  [SC21/WG3  N  1646]. 

An  SWG-MF  meeting  on  modelling  facilities  held  in  Namur,  Belgium  in  December  1992 
yielded  papers  on  the  following  topics: 

•  Modeling  facilities  proposal  for  a  new  program  of  work  [SC21  N  7546] 

•  Interrelationships  between  a  conceptual  schema  modelling  facility  (CSMF)  and  a  data 
modelling  facility  (DMF)  [SC21  N  7545] 

•  Requirements  for  standard  modelling  facilities  [SC21  N  7544] 

•  Use  of  standard  modelling  facilities  in  the  definition  of  JTC1  and  other  ISO  standards 
[SC21  N  7543]. 

The  final  report  of  the  SWG-MF  [SC21  N  8056]  emphasized  the  last  topic,  using  standard 
modelling  facilities  in  the  preparation  of  standards.  The  SWG-MF  proposed  the  following 
definitions  [Ref.  SC21  N  7542  1993]: 

•  Data  Modeling  Facility  (DMF) — a  system  (possibly  incorporating  methods,  languages, 
software  tools,  etc.)  that  enables  and  supports  some  or  all  of  the  activities  surrounding 
a  data  model,  that  is,  its  creation,  update,  management,  linkage  with  external 
knowledge  representations,  and  all  relevant  services  involved  in  its  life  cycle. 

•  Conceptual  Schema  Modeling  Facility  (CSMF) — a  system  that  enables  and  supports 
the  activities  surrounding  a  conceptual  schema.  Since  a  conceptual  schema  subsumes 
a  data  model,  any  CSMF  must  contain  or  interoperate  with  one  or  several  DMFs. 

The  SWG-MF  identified  the  following  standards  and  standards  projects  as  already  making 
use  of  a  DMF:  ODA  (ISO  8613),  IRDS  Services  Interface  (ISO/IEC  10728),  Design  Support  for 
SQL92  Applications  (SC21/WG3),  Database  Language  SQL  (ISO/IEC  9075:1992),  Information 
Framework  (ISO  9594-2),  Selected  Attribute  Type  (ISO  9594-6),  Selected  Object  Classes 
(ISO  9594-7),  Management  Information  Model  (ISO/IEC  10165-1),  Definition  of  Management 
Information  (ISO/IEC  10165-2),  Application  Layer  Structure  (ISO/EEC  9545),  Data  Flow 
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Diagrams  (SC7/WG1),  State  Transition  Diagrams  (SC7/WG1),  Product  Data  Exchange  - 
EXPRESS  (ISO/IEC  10303-11),  CASE  Interchange  Metamodel  (EIA/CDIF),  and  Reference 
Model  for  Computer  System  Tools  (IEEE  PI  175).  Projects  likely  to  make  use  of  a  DMF  in  the 
future  are  Conceptual  Schema  for  Open  EDI  (JTC1/WG3),  Data  Element  Coordination  Group 
(TAG7/DCG-NIAM  DMF),  Guidelines  for  Design  of  IRDS  Content  Modules  (SC21/WG3),  ODP 
SC21/WG7),  Data  Elements  and  Exchange  Formats  (TC46/SC3),  and  Data  Elements 
(TC46/SC4/WG7 ) .  [Ref.  SC21  N  8057  1993] 

SC21  approved  a  new  work  item  proposal  on  Conceptual  Schema  Modeling  Facility , 
June  1993  [SC21  N  8060].  This  work  would  standardize  a  CSMF  as  the  basis  for  specifying 
concepts  and  terms  about  one  or  more  subject  areas  (e.g.,  areas  for  standardization) — the  CSMF 
would  assist  in  building  an  abstract  model  of  the  subject  area.  A  CSMF  is  viewed  as  an  urgent 
need  to  provide  a  consistent  facility  to  be  used  in  preparing  other  standards.  At  its  plenary  in  June 
1993,  SC21  dissolved  the  SWG-MF  and  established  a  rapporteur  group  under  WG3  to  progress 
contributions  on  CSMF  on  an  interim  basis  based  on  a  draft  contribution  [SC21 N  8086].  Work 
by  the  CSMF  Rapporteur  Group  was  directed  to  be  on  use  of  modelling  facilities  in  standards 
preparation.  The  focus  of  work  on  data  modelling  was  directed  to  be  limited  to  identifying 
requirements  for  the  use  of  a  DMF  in  the  preparation  of  standards  and  reviewing  existing  DMF 
standards  for  applicability  rather  than  creating  a  new  DMF  standard.  [Ref.  SC21  N  8081  1993; 
DRA  1994]  The  CSMF  Rapporteur  Group  met  in  January  1994  to  define  concepts,  terms, 
principles,  functional  capabilities,  and  framework  for  standard  Cosmos  [Ref.  SC21  N  8282  1993]. 
The  next  meeting  is  planned  for  July  1994  [Ref.  SC21  N  8127  1993]  The  following  are 
recommended  standards  and  related  documents  for  CSMF  work  [Ref.  JTC1  N  2775  1993]: 

•  A  Data  Modelling  Facility:  JDMF/MODEL-1992  [SC21  N  8305  1993]  (English 
translation  of  a  document  from  the  Japanese  Standards  Association) — describes  data 
construction  rules  for  an  application  data  model  (defined  to  be  a  model  of  an  object 
world  from  a  data  point  of  view)  shared  for  many  purposes  and  a  representation 
method  of  describing  such  a  data  model.  Data  construction  rules  ate  characterized  as 
consisting  of  data  structures  describing  relationships  among  data  and  integrity 
constraints  to  be  satisfied  among  data.  The  facility  defined  by  this  document  is  an 
object-oriented  data  modelling  facility  in  the  sense  that  its  basic  component  is  an  object 
embodying  data  about  itself  and  operations  applicable  to  it 

•  Conceptual  Schema  Specification  for  Data  Interchange,  ANSI/X3  689-D 

•  Information  Resource  Dictionary  System  Normative  Schema ,  ANSI  X3  988-D 

•  ISO  TR  9007,  Concepts  and  Terminology  for  Conceptual  Schema  and  Information 
Base 

•  As~*ssment  Guidelines  for  Conceptual  Schema  Language  Proposals 
[SC21/WG5  N  236] 

•  ISO/IEC  10303-11,  Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  11:  EXPRESS  (Language  Reference  Model). 

6. 2. 5. 4  Object-Oriented  Database  Support 

In  1989,  the  ANSI  X3  Standards  and  Planning  Requirements  Committee  (SPARC) 
Database  Systems  Study  Group  organized  the  Object-Oriented  Database  Task  Group  (OODBTG) 
to  gather  information  on  object  database  management  systems  and  to  recommend  standards  needed 
in  this  area.  Their  final  report,  issued  in  October  1991,  contains  the  following  [Ref.  ANSI  1991 J: 

•  Recommendations  for  standards  in  object  data  management 

•  Reference  model  for  object  data  management 
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•  Glossary  of  object  data  management  terms 

•  Report  on  a  survey  of  object  data  management  systems 

•  Report  on  workshops  on  object  data  management  standardization. 

In  June  1991,  SC21/WG3  recommended ‘that  SQL  support  for  objects  continue  to  be 
developed  via  the  SQL3  specification  and  that  the  Reference  Model  rapporteur  group  consider  other 
requirements,  as  appropriate  beyond  SQL.  [Ref.  Gallagher  1991]  WG3  posed  a  question 
(Q3/001)  on  support  for  object  orientation  in  database.  In  its  answer  to  Q3/001,  WG3  stated  that 
for  the  purpose  of  WG3,  the  question  is  resolved  by  the  SQL-3  related  work  being  done  in  support 
of  the  object  paradigm. 

In  early  1992,  ANSI  X3  announced  the  formation  of  a  new  technical  committee,  X3H7, 
Object  Information  Management  (OIM).  The  object  paradigm  is  increasingly  used  as  a  basis  for 
interoperability  in  the  areas  of  object  data  management,  object  programming  languages,  object 
networking,  object  analysis  and  design,  and  object  user  interfaces.  X3H7  will  develop  a  reference 
model  technical  report  the  scope  of  which  will  include  the  following  [Ref.  X3  1992]: 

•  An  interoperable  object  model 

•  Object  data  management  services 

•  External  representations  of  object  model  schema  and  data 

•  Object  class  libraries 

•  Object  languages 

•  Object  communication  and  distribution 

•  Object  design  and  methodologies. 

The  final  standard  from  ANSI  X3H7  (Object  Information  Management  committee)  will  be 
the  tool  for  providing  connectivity  between  many  different  standards.  The  committee  is  providing 
a  framework  for  harmonizing  the  different  object  models,  object  interaction  designs,  object 
database,  and  distributed  system/object  standards.  The  core  of  the  initial  standard  is  a  "Features 
Matrix"  that  provides  a  comparison  of  the  object  models  of  existing  object  database  models.  The 
standard  is  being  developed  with  the  coordination  of  several  other  ANSI  committees  and  die  Object 
Management  Group  (OMG).  It  is  expected  to  be  available  for  coordination  by  1994.  [Ref. 
CFS  1993c] 

6. 2.5. 5  Full  Text  Manipulation  in  Structured  Data 

SC21/WG3  is  including  in  its  work  on  SQL  standardizing  support  for  full  text 
manipulation  in  combination  with  the  management  of  structured  data  using  SQL.  SQL:  1992 
supports  storage  of  a  collection  of  text  as  a  single  data  value,  but  is  not  capable  of  the  complex 
requirements  for  full  text  manipulation.  [Ref.  SC21  N  5141  1990]  A  special  WG3  ad  hoc  meeting 
on  the  question  of  Free-Text  Database  (Q3/002)  recommended  that  full  text  be  pursued  as  part  of  a 
broader,  new  project  on  SQL/Multimedia  (see  Section  6.2.2.2).  [Ref.  SC21  WG3  N  1430 1992] 

6.2.6  Transaction  Processing 

A  transaction  is  a  logical  set  of  operations  characterized  by  the  four  properties:  atomicity, 
consistency,  isolation,  and  durability  (ACID).  The  atomicity  property  means  that,  to  an  outside 
observer,  either  all  of  the  operations  are  completed  or  none  of  them  is  executed.  The  consistency 
property  means  that  the  operations  are  performed  correctly  with  respect  to  the  application 
semantics.  The  isolation  property  means  that  any  partial  results  of  the  operations  composing  the 
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atomic  action  are  not  accessible  before  the  completion  of  the  atomic  action.  Finally,  the  durability 
property  means  that  die  action  must  endure  a  communication  or  an  application  failure. 

The  OSI  Transaction  Processing  (TP)  standard  (ISQflEC  10026)  provides  an  infrastructure 
to  support  distributed  transaction  processing  which  may  span  across  one  or  more  open  systems.  It 
provides  mechanisms  to  ensure  the  ACID  properties  of  a  distributed  transaction  and  a  transaction 
processing  environment  involving  a  number  of  application  associations.  TP  concepts,  standards, 
and  profiles  are  described  with  other  network  services  in  Section  9.1 1.9. 

6.2.7  Other  Database  Service  Standards 

CODAS YL  data  management  standards  are  the  responsibility  of  the  CODASYL  Systems 
Committee.  A  report  on  distribution  alternatives  and  generic  architectures  for  distributed  database 
systems  was  produced  by  this  committee  in  1980.  [Ref.  CODASYL  1980]  One  of  the  two 
standard  ISO  data  management  languages  (NDL)  is  based  on  CODASYL  concepts. 

In  1985,  ECMA31  issued  a  final  draft  report  [Ref.  ECMA  1985]  for  remote  database  access 
service  and  protocol. 

ANSI  standards  for  database  architectures  are  produced  by  the  Database  Architecture 
Framework  Task  Group  (DAFTG)  through  the  Standards  and  Planning  Requirements  Committee 
(SPARC).  A  draft  report  [Ref.  DAFTG  1982]  from  the  DAFTG  in  1982  provided  a  framework  to 
support  distributed  databases,  multiple  data  models,  and  data  dictionaries.  One  concept,  the 
ASN.l,  has  been  specified  [ISO  8824  and  8825], 

ITU-TS  does  not  provide  standards  for  data  management  The  US  Government  Open 
Systems  Interconnection  Profile  (GOSIP,  see  Section  16.1.3.1)  does  not  address  standards  for 
data  management  [Ref.  GOSIP  1988] 

6.3  Standards  for  Data  Management 

6.3.1  Data  Element  Standardization 

The  following  standard  related  to  data  management  has  been  developed  for  the  US  DoD: 

•  DoD  8320.1-M-l,  DoD  Data  Element  Standardization  Procedures,  ASD(C3I), 
January  1993,  UNCLASSIFIED. 

Others  are  being  developed: 

•  DoD  Instruction  8020.1,  Functional  Process  Improvement  Program,  Draft  1  October 
1992,  ASD(C3I),  UNCLASSIFIED 

•  DoD  8020. 1 -M,  Functional  Process  Improvement  ( Functional  Management  Process 
for  Implementing  the  Information  Management  Program  of  the  Department  of 
Defense),  Draft  5  August  1992,  UNCLASSIFIED 

•  DoD  8320.1,  DoD  Data  Administration,  ASD(C3I),  26  September  1992, 
UNCLASSIFIED 

•  DoD  8320.1-M-X,  DoD  Data  Model  Development,  Approval,  and  Maintenance 
Procedures,  Draft  May  1993,  UNCLASSIFIED 

•  The  DoD  Enterprise  Model,  Volume  I,  Strategic  Activity  and  Data  Models, 
January  1994. 


31  ECMA  full  membership  is  open  only  to  companies  who  develop,  manufacture,  and  sell  computers  in  Europe. 
The  restricted  membership  makes  full  consensus  among  participants  in  sfandards-making  easier  and  quicker  to 
reach  than  in  ISO. 
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The  US  DoD  has  mandated  that  “DoD  operations  shall  be  executed  through  integrated  and 
standard  Department-wide  process,  data  definitions,  and  information  systems  in  support  of  joint 
warfighting  and  peacetime  missions”  [Ref.  DoD  Instruction  8020.1  1992].  The  DoD  has 
developed  standards,  many  still  in  draft  form,  to  implement  centralized  data  administration, 
including  DoD  8320.1,  8320. 1-M,  and  8320.1-M-l.  Such  data  administration  seeks  data 
standardization  that  supports  the  following: 

•  Providing  clear,  concise,  consistent,  unambiguous,  easily  accessible  data  DoD-wide 

•  Minimizing  the  cost  and  time  required  to  transform,  translate,  or  research  differently 
described,  but  otherwise  identical,  data 

•  Supporting  data  sharing  and  interoperability  among  information  systems  throughout 
die  DoD 

•  Providing  uniform  description  and  representation  of  data. 

Data  element  standardization  will  be  governed  by  DoD  8320.1-M-l.  As  atomic  single¬ 
concept  specifications,  data  elements  will  be  defined  and  classified  to  represent  the  attributes  of 
data  entities  identified  in  entity-attribute-relationship  data  models.  Their  definitions  will  be  based 
on  data  entities  and  their  associated  attributes  established  in  a  DoD-wide  data  model.  Single¬ 
concept  data  elements  will  be  specified  to  promote  shareability  and  data  independence  for 
applications. 

ISO  has  issued  a  standard  (DIS  7826)  on  the  representation  of  data  elements.  This  draft 
proposal  sets  out  standard  procedures  for  the  identification  and  representation  of  existing  and  new 
coding  systems,  without  providing  any  guidance  on  specific  coding  systems.  It  also  specifies  a 
technique  for  interchange  of  coded  representations  and  the  requirements  for  the  administration  of 
International  Coding  System  Identifiers  (ICSIs).  This  will  permit  the  use  of  more  than  one  coding 
system,  reduce  the  possibility  of  ambiguity,  reduce  the  need  for  human  intervention,  and  diminish 
the  time  required  to  negotiate  interchange  of  coded  representation  agreements.  DIS  7826  identifies 
three  types  of  data  element  attributes:  administrative,  relational,  and  representative. 

The  US  Army  has  published  an  Army  Regulation  (AR  25-9)  [Ref.  DISC4  1988]  to 
prescribe  policies,  responsibilities,  and  concept  of  operation  for  the  management  of  data  used  in 
manual  and  automated  information  systems  throughout  the  US  Army.  This  document  has  been 
coordinated  with  ISO,  ANSI,  and  the  NIST,  as  well  as  with  the  US  Joint  Chiefs  of  Staff,  to 
ensure  alignment  in  the  area  of  a  data  element  naming  convention.  The  US  Army  plans  to  maintain 
a  Service-wide  data  encyclopedia  of  information  about  all  data  elements  that  have  gone  through  a 
standardization  process  and  are  designated  as  Army  standard  elements.  AR  25-9  has  been  used  for 
initial  work  on  data  element  standardization  for  CIM.  Additional  information  on  AR  25-9  is 
provided  in  ATCCIS  WP  7L.  [Ref.  WP7L  1989] 

Substantial  work  has  been  done  cooperatively  by  ISO  JTC1/SC14  and  ANSI  X3L8  during 
the  last  5  years.  This  work  has  resulted  in  an  X3L8  document  entitled  Coordination  of  Data 
Elements,  which  was  accepted  by  SC14  as  document  SC  14  N  492.  It  is  DIS  1 1 179,  which  has 
six  parts.  Two  other  ISO  Technical  Reports  are  in  progress: 

•  DTR  7352,  Guidelines  for  Grouping  of  Data  Elements  in  the  Context  of  Data 
Interchange 

•  PDTR  9789,  Guidelines  for  Data  Interchange  -  Coding  Methods  and  Principles 

The  objective  is  for  application  areas  to  interchange  data  among  themselves  predicated  on  shared 
generic  concepts  that  would  be  documented  in  a  Data  Element  Concept  Taxonomy.  [Ref. 
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Kenworthy  1991]  The  general  approach  to  the  structure  of  data  recommended  in  AR  25-9  and 
ATCCIS  WP  7L  was  derived  from  discussions  with  ISO  JTC1/SC14  and  ANSI  X3L8. 

6.3.2  NATO  Policy  and  Issues  for  Data  Management 

6. 3. 2.1  NACISC  Policy  on  Data  Management 

In  June  1993,  the  NACISC  promulgated  a  data  management  policy  for  NATO  [Ref. 
NATO  1993a].  It  provides  a  NATO  policy  for  data  management  throughout  the  NATO 
Interconnected  Information  System  (NIIS).  It  specifies  the  requirements  and  identifies  the 

(1)  elements  of  data  management  subject  to  NATO  policy,  procedures,  and  standardization  and 

(2)  the  activities  required.  It  further  identifies  the  extent  of  standardization  required  for  different 
elements  of  data  management  The  scope  of  the  policy  is  to  fulfill  the  requirements  to:  identify  the 
responsibilities,  organizations,  and  roles  for  data  management  within  NATO;  define  data 
management  and  its  elements  and  the  extent  to  which  they  are  subject  to  a  NATO  policy;  state  the 
principles,  rules,  standards,  and  procedures  for  the  planning  and  implementation  of  data 
management;  and  identify  the  implications/overheads  of  successfully  implementing  data 
management  Table  7  provides  excerpts  from  the  policy  document 

6. 3. 2. 2  ADSIA  Recommendations  on  Data  Management 

In  April  1986,  ADSIA  revised  a  working  paper  [Ref.  ADSIA  1987]  on  the  need  for 
standardization  of  data  management  The  following  actions  were  recommended: 

•  NATO  Communications  and  Information  Systems  Agency  (NACISA)  to  identify  and 
collect  the  requirements  for  database  management  systems  and  for  standardization  of 
database  schemes,  file  transfers,  database  information  exchange,  and  configuration 
management  procedures 

•  Subsequently,  the  Information  Systems  Working  Group  (ISWG)  to  develop  a  NATO 
policy  on  data  management  and  on  die  use  of  database  management  systems  in  NATO 
information  systems 

•  ADSIA  to  coordinate  the  development  of  technical  and  procedural  standards  for 
databases 

•  ADSIA  to  develop  the  procedural  standards  for  database  information  exchange 

•  TSGCE  SG9  to  develop  technical  standards  for  database  schemes  and  file  transfer 

•  NACISA  to  control  the  implementation  of  the  developed  standards  and  NATO  policy 
paper  to  ensure  the  interoperability  of  command  and  control  systems  within  the  NATO 
information  system. 

6. 3. 2. 3  NATO  Interoperability  Management  Plan  (NIMP) 

Many  aspects  of  data  management  are  procedural  in  nature  and  will  be  controlled  by 
procedural  and  not  technical  standards.  Several  of  these  standards  are  also  identified  below.  The 
NATO  Interoperability  Management  Plan  (NIMP)  [Ref.  NIMP  1988]  specifically  identifies 
standards  and  rules  for  representing  data  as  information  procedural  standards  and  assigns  the 
responsibility  for  these  standards  to  the  Allied  Data  Systems  Interoperability  Agency  (ADSIA).  To 
emphasize  the  role  of  data  management  in  achieving  interoperability,  the  NIMP  states: 

In  order  far  the  information  exchange  to  be  effective,  it  is  necessary  that  the  meaning 
and  relationships  associated  with  that  information  / received  from  other  facilities]  is 
common  and  preserved,  irrespective  of  the  interoperability  service  and  transmission 
media,  A  single  common  definition  for  all  operational  information  throughout 
NATO  is  needed  to  achieve  this  goal 
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•  Efficient  interoperability  in  the  NATO  Interconnected  Information  System  (NIIS)  requires  consistency  and 
integrity  of  data  throughout  these  systems.  This  in  turn  requires  the  application  of  NATO-wide  standards  and 
procedures  for  data  management  in  this  situation.  The  use  of  invalid  data  or  the  incorrect  interpretation  of  data 
by  other  information  systems  can  be  disastrous  for  any  type  of  operations.  Each  form  of  data  exchange  is 
worthless  unless  the  meaning  of  data  is  understood  unambiguously  on  both  sides.  Furthermore,  if  data  is 
represented  in  different  ways,  translation  will  be  required,  which  in  turn  hinders  effective  communication. 
Therefore,  data  management  with  its  inter-system  functions  has  to  be  planned  and  implemented  to  support  the 
interoperation  of  systems  by  preserving  meaning  and  relationship  in  the  exchange  of  data.  (Emphasis  added.) 

•  Data  management  is  defined  as  the  planning  for,  organization,  and  control  of  data  utilizing  rules,  procedures, 
people,  methods,  and  tools  to  identify,  define,  and  represent  the  meaning  and  relationship  of  data  and  to  ensure 
its  availability,  quality,  integrity,  and  security.  Data  management  addresses  all  functions  needed  for  the 
definition,  storage,  retrieval,  manipulation,  protection,  and  distribution  of  data. 

•  Data  management  functions  support  the  operation  of  a  stand-alone  as  well  as  distributed  systems  and  the 
information  exchange  among  systems.  These  functions  are 

-  Data  security— the  protection  of  data  from  either  accidental  or  unauthorized  intentional  modification, 
destruction,  or  disclosure. 

-  Data  definition— the  operational  meaning  of  data,  relationship  with  other  data,  data  labelling  (including 
classification),  and  representation  of  the  data  in  information  systems  and  in  the  information  exchange  with 
other  systems. 

•  Data  manipulation— the  capability  to  perform  data  operations  in  local  and  remote  databases;  typical  data 
operations  are  to  retrieve,  store,  append,  update,  and  delete  data. 

-  Data  distribution — the  capability  to  disseminate  data  among  databases  and  systems,  whose  pattern  of 
distribution  is  dependent  upon  the  operational  need  to  provide  information  to  interoperating  information 
systems. 

-  Data  availability— the  capability  to  enable  the  users  to  access  their  data  from  predetermined  locations,  within 
agreed  response  times,  and  must  expect  recovery  with  predesignated  times  following  preplanned, 
accidental,  or  other  loss  of  service.  This  implies  five  subfunctions: 

--  Data  monitoring— observes  the  values  of  elements  in  the  database  for  analysis 

-  Data  transaction  monitoring — logs  data  transactions  and  maintains  statistics  with  a  view  to  analyzing 
and  verifying  he  performance  of  data  management 

-  Data  backup— Is  concerned  with  the  provisions  and  procedures  to  provide  the  data  for  recovering  after  a 
system  failure  in  any  form  to  ensure  continuous  operation  with  correct  data 

-  Data  recovery— performs  all  the  actions  necessary  to  allow  recovery  of  data  after  system  failures 

-  Data  audit  trails — deals  with  the  provisions,  procedures,  and  data  for  tracing  the  transactions  that  have 
affected  the  data. 

•  Data  management  functions  are  supported  by  the  following  tools: 

•  Data  model — an  abstract  representation  (description)  of  real  world  items  that  represents  structure 
(organization)  of  data  and  may  exist  in  graphical  format  (e.g.,  entity-relation  diagram)  and  a  formal 
specification  (schema)  described  by  use  of  a  data  definition  language,  and  corresponding  entries  in  a  data 
dictionary. 

Data  dictionary— a  database  that  contains  metadata  (data  about  data)  and  rules  that  deal  with  the  use  and 
structure  of  data  objects  of  a  certain  set  of  applications. 

•  Database  management  system  (DBMS)— a  computer-based  system  for  defining,  creating,  manipulating, 
controlling,  managing,  and  using  databases.  A  DBMS  should  have  at  least  the  following  functions:  support 
data  definition,  perform  data  manipulation,  support  data  security,  maintain  data  integrity,  perform  data 

_ monitoring,  manage  data  distribution,  support  date  recovery,  and  perform  data  system  monitoring. _ 

Source:  NATO  Data  Management  Policy,  June  1983  [NACISC  1993a]. 

6. 3. 2.4  SHAPE  Policy 

The  purpose  of  data  management  in  NATO  is  to  provide  methods  to  ensure  data 
availability,  security,  integrity,  quality,  and  interoperability,  and  to  provide  data  sharing.  The  ACE 
Manual  (AM)  on  Data  Management,  AM  96-1-4  [Ref.  SHAPE  1988],  defines  data  as  representing 
the  elementary  facts,  descriptions,  and  qualifications  about  things  of  interest  to  some  headquarters, 
unit  activity,  or  enterprise.  It  further  defines  the  role  of  a  data  dictionary  as  an  automated  tool  that 
provides  a  centralized  library  of  metadata  covering  all  aspects  of  all  types  and  structures  of  data 
residing  in  databases,  file  systems,  and  manual  systems  within  an  organization.  AM  96-1-4 
further  asserts  that: 

•  Evolution  towards  an  ACE  ACCIS  will  only  succeed  from  the  data  management  point 
of  view  by  ensuring  that  the  standardization  of  data  definitions,  the  control  of  the  data. 
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and  the  maintenance  of  its  overall  integrity  are  systematically  established  on  a 
command  or  site  basis. 

•  The  fundamental  key  to  data  management  is  the  early  definition  and  identification  of 
data  elements  and,  later,  data  fields.  The  definition  and  corresponding  name  should  be 
clear,  accurate,  and  meaningful,  but  reference  should  be  given  to  connotation,  which 
relates  to  the  interpretation  that  bears  upon  the  specific  context  of  usage  of  data. 

6. 3. 2. 5  STC  Work 

In  1973,  Shape  Technical  Centre  (STC)  published  a  Technical  Memorandum  (TM)  (TM- 
776)  on  data  management  standardization  for  the  ACE  ACCIS  [Ref.  SHAPE  1985].  TM-776 
recommends  standardization  of  the  architecture,  functionality,  and  structure  of  the  Data 
Management  Subsystem  (DMS)  of  the  ACE  ACCIS.  These  areas  of  standardization  include  data 
management  methodologies  and  the  tools  used  to  design,  build,  and  maintain  the  ACE  ACCIS 
databases.  TM-776  accomplished  the  following: 

•  Identified  the  requirement  that  the  DMS  at  each  ACE  ACCIS  node  must  agree  on  the 
semantics  and  syntax  of  the  information  exchange. 

•  Recommended  that  there  be  a  standard  ACE  data  definition  or  conceptual  schema, 
where  a  schema  defines  all  application  object  types,  including  their  attributes, 
relationships,  and  static  constraints,  and  where  a  database  is  an  instance  of  a  schema. 

•  Stated  that  a  data  classification  method  must  be  used  that  is  based  on  the  principle  of 
sorting  data  according  to  the  type  of  information  provided  by  their  values,  independent 
of  their  use  in  particular  databases,  messages,  or  applications. 

•  Identified  the  need  for  a  methodology  for  formal  definition  of  data  elements  based  on 
standardized  terminology,  including  die  use  of  naming  conventions: 

A  data  element  is  defined  as  a  basic  unit  of  data  dial  has  a  name,  a  definition,  and 
a  set  of  values  for  representing  particular  facts.  A  data  element  and  its  definition 
should  not  include  any  application  or  usage  information. 

A  method  is  needed  for  analyzing,  defining,  and  controlling  data  elements.  This 
method  should  have  three  components:  a  type  classification  of  data  elements, 
syntax  rules  for  the  structure  and  completeness  of  formal  definitions,  and  a 
controlled  vocabulary  of  permitted  terms  for  formal  definitions. 

Standard  data  elements  and  relationships  should  be  placed  into  an  ACE  common 
data  structure. 

Since  1991,  STC  has  been  developing  recommendations  for  data  administration  in  ACE. 
The  paper  is  currently  a  draft  technical  note.  Recommendations  for  ACE  Data  Administration, 
TN-444,  Draft  Version  1.2  [Ref.  STC  TN-444  1993].  The  report  aims  to  serve  as  conceptual 
guidance  in  the  establishment  of  data  administration  for  ACE  and  proposes  a  definition  of  data 
administration  activities,  the  methods  to  be  applied,  the  support  facilities  required,  and  an 
organizational  structure  and  activity  plan  for  starting  the  establishment  of  ACE  data  administration. 

Data  administration  is  defined  in  STC  TN-444  as  referring  to  die  non-technical  activities  of 
planning  and  implementation  for  the  database  environment  These  activities  include  the 
prescription  of  policies  and  standards,  planning  and  coordination,  conflict  resolution,  logical 
database  design,  and  security  control.  At  present  there  is  no  assigned  responsibility  for  ACE  data 
administration.  There  are  some  regional  data  administration  activities,  but  these  activities  are  not 
guided  by  ACE  standards.  Further,  project-related  data  definition  activities  are  uncoordinated. 
[STC  TN-444  1993] 
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Work  conducted  in  support  of  the  system  design  and  integration  contract  (SD&IC)  for  the 
ACE  ACC IS  on  data  models  had  the  following  deficiencies:  lack  of  traceability  between  sources 
(messages,  directions,  etc.)  and  the  data  model;  lack  of  integration  (the  data  model  is  basically 
message  oriented  with  little  cohesion  between  the  ‘‘message  models”);  and  lack  of  completeness 
(the  data  model  was  based  on  a  subset  of  sources  that  did  not  cover  all  relevant  information 
requirements).  The  most  successful  data  standardization  activities  taken  so  far  within  ACE  and 
NATO  (and  among  the  NATO  nations)  appear  to  be  in  the  context  of  message  standards  (the  work 
in  ATCCIS  is  an  exception  to  this  observation).  However,  the  standards  [e.g.,  ADatP-3,  ACE 
Directive  (AD)  80-50,  regional  supplements  to  AD  80-50]  are  inconsistent  [STC  TN-444  1993] 

6. 3. 2. 6  NATO  Publications  on  Data  Management 

AAP-6,  NATO  Glossary  of  Terms  and  Definitions  (English  and  French),  standardizes 
terminology  used  throughout  NATO,  thereby  promoting  mutual  understanding.  The  criterion  for 
inclusion  is  that  the  term  be  of  a  general  military  application.  While  earlier  editions  put  qualifiers 
immediately  following  the  term,  such  qualifiers  are  now  embedded  in  the  definition.  In  addition, 
terms  and  definitions  are  not  to  be  composed  of,  nor  contain,  abbreviations  and  acronyms.  A  term 
and  definition  are  included  in  the  glossary  only  when  they  have  been  agreed  upon  by  all  nations  in 
both  English  and  French. 

The  terms  defined  in  ADatP-2  [Ref.  ADatP-2  1985],  Automatic  Data  Processing  (ADP) 
NATO  Glossary,  English  and  French,  are  derived  from  glossaries,  dictionaries,  and  vocabularies 
from  ANSI,  American  National  Directory  for  Information  Processing,  ISO,  International  Business 
Machines,  and  ACP  167.  The  definitions  are  annotated  by  source  and  may  include  abbreviations, 
examples,  notes,  diagrams,  accepted  synonyms,  contrasting  terms,  related  terms,  and  cross- 
references  for  multiple  uses.  This  information  is  noted  when  harmonization  is  being  examined  for 
multiple  uses. 

ADatP-3  (STANAG  5500)  [Ref.  ADatP-3  1986],  NATO  Message  Text  Formatting  System 
(FORMETS),  provides  the  rules,  constructions,  and  vocabulary  for  standardized  character-oriented 
message  text  formats  that  can  be  used  in  both  manual  and  computer-assisted  operational 
environments. 

ACP  167  [Ref.  ACP  167  1981],  Glossary  of  Communications-Electronics  Terms, 
provides  definitions  of  terms  used  by  communications,  electronic  warfare,  and  operational 
personnel  for  Allied  networks. 

6.3.3  Data  Management  Issues  in  EDI 

The  Special  Working  Group  on  Electronic  Data  Interchange  (SWG-EDI)  of  JTC1  has 
identified  a  number  of  data  management  issues  that  require  coordination  within  JTC1  (SCs  14, 18, 
21,  and  24)  and  with  other  Technical  Committees  (TCs)  such  as  TC  46, 68, 154,  and  184.  The 
issues  include  [Ref.  SC21  N  3925  1989]: 

•  Ensuring  a  complete  separation  of  the  semantics  and  form  of  data  elements,  for  which 
the  conceptual  schema  is  defined  at  a  level  other  than  the  actual  applications 

•  Accommodating  different  types  of  data  representations,  specifically  with  regard  to  the 
data  models  for  different  types  of  data,  so  as  to  assure  that  logical  relationships 
between  data  of  different  types  can  be  expressed 
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•  Strocturing  precisely  the  dictionaries  of  data  elements  and  groupings,  to  include  all  the 
attributes  of  data  elements  and  to  permit  unambiguous  reference  to  other  directories 

•  Assuring  coherence  of  dictionaries  across  time  (updating  and  maintenance)  and 
sectors,  and  also  with  generic  dictionaries. 

6.3.4  Data  Management  for  Distributed  Applications 
The  Workshop  on  Distributed  Applications  held  by  JTC1  in  March  1990  noted  that  "very 
similar  data  management  requirements  are  being  addressed  by  differing  standards  applications"  and 
that  "potential  exists  for  prevention  of  a  considerable  amount  of  duplication  of  effort  and 
overiap...by  increasing  the  extent  of  utilization  of  common  aspects  of  data  management  facilities." 
Coordination  was  recommended  among  SC21/WG3  (Database)  and  WG7  (ODP),  SC  14,  SCI  8, 
SC22,  SC24,  SWG-EDI,  TC46,  and  ITU-TS  SGs  VD  and  Vm.  Table  8  identifies  common 
requirements  for  data  structures  and  data  models  being  addressed  in  ISO.  [Ref.  SC21  N  4524 
1990] 

Table  8.  Data  Management  Requirements  Identified  in  ISO 
Relating  to  Data  Structures  and  Data  Models 

•  f^sderstsd  data  mcxMi 

•  Mapping  to  uMr-ortentad  data  structurea/operationa 

•  Ability  to  auppoft  accaaa  control  to  data  atructurea 

•  Wide  range  of  sizes— laigs  and  amal  volumea  of  data 

•  Logging  of  operations  for  audk 

•  Ability  to  combine  separately  defined  data  types  (static  and  dynamic) 

•  Application-oriented  operations  (e.g.,  searching) 

•  Support  for  intemationaRzatk>n 

•  Version  control  (inchxSng  data  structure  modifications) 

•  Distribution,  transparency  support,  and  modaWng  location 

•  Handing  of  unintsrpratsd  data 

•  Support  of  dWarent  levels  of  consistency  and  data  integrity 

•  Ability  to  relate  famMes  of  specWcatione  for  dHerent  levels  of  abstraction 

•  Support  for  recursive  and  structured  definitions 

•  Persistent  storage  of  results  of  operations 

•  Ability  to  support  pointer  types 

•  Abiity  to  support  powerful  query  languages 

•  Support  for  Directed  Acydc  Graphs  (inducing  selection) 

•  Support  for  uniqueness  requirements 

•  motpanoanct  TrofTi  progrirTRnng  wnguigN  mQ  means  w  Kctci 

•  Support  of  declaration  of  hotspots  and  triggers 

•  Choice  of  granularity 

Source:  Conakhratbn  of  tho  Data  Management  Component  of  Application 
Standard »,  Woricshop  on  Distributed  AppteaHons  (SC21  N  4624],  April  1990. 

A  special  WG3  ad  hoc  meeting  in  May  1992  on  the  question  on  distributed  database 
(Q3/007)  addressed  two  future  alternatives:  (1)  that  distributed  database  be  considered  a  very 
broad  topic  with  required  liaison  and  cooperation  with  other  parts  of  WG3,  especially  ODP,  or 
(2)  that  distributed  database  be  narrowly  scoped  with  possibly  a  piece  in  RDA  and  a  piece  in  SQL. 
No  conclusion  was  reached  and  the  question  will  remain  open  pending  further  contributions.  A 
further  meeting  was  held  in  June  1993  in  Yokohama,  Japan  immediately  prior  to  the  WG3 
meetings.  [Ref.  SC21 WG3  N 1430  1992] 

6.4  Assessment  of  Coverage  by  Standards 

Data  management  services  include  the  data  dictionary/directory  component  for  accessing 
and  modifying  data  about  data  (i.e.,  metadata),  the  database  management  system  component  for 
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accessing  and  modifying  structured  data,  and  the  distributed  data  component  for  accessing  and 
modifying  data  from  a  remote  database.  [Ref.  APP 1993] 

While  the  ANSI  standard  (ANSI  X3. 138-1988)  and  FIPS  156  are  the  same,  ISO  is 
working  on  an  Information  Resource  Dictionary  (IRDS)  specification  ( IRDS  Framework , 
ISO  10027)  that  is  significantly  different  in  some  respects  from  the  ANSI  standard.  FIPS  156 
does  not  completely  specify  interface  services  for  a  data  dictionary/repository — it  specifies  only  the 
user  interface.  ANSI  X3.185  (ISO  10728),  IRDS  Services  Interface,  provides  an  API  to  IRDS 
and  is  appropriate  for  metadata  interchange  with  a  DBMS  and  between  an  IRDS  and  application 
programs.  ANSI  X3.195,  IRDS  Export-Import  File  Format,  supports  schema  and  metadata 
interchange  among  IRDS-compliant  databases,  among  IRDS  and  CASE  tools  with  repositories  or 
dictionaries,  and  between  IRDSs  and  application  programs.  Additional  functionality  is  needed  for 
IRDS,  to  include  the  capability  to  manage  object-oriented  data  structures  and  to  provide  for 
enhanced  communication  of  information  between  applications  and  other  data  management  tools.  A 
major  revision  of  IRDS,  sometimes  called  IRDS2,  is  underway  and  is  expected  to  provide  such 
functionality. 

A  standard  relational  DBMS  interface  is  provided  by  Database  Language  SQL  (FIPS  127-2 
and  ISO  9075:1992,  sometimes  known  as  SQL2),  which  incorporates  ANSI  X3. 138:1989  (SQL) 
and  ANSI  X3.168  (Embedded  SQL),  together  with  additional  features  for  schema  manipulation, 
dynamic  SQL,  exception  handling,  enhanced  integrity  constraints,  transaction  management,  and 
data  administration.  Not  yet  addressed  are  access  to  remote  heterogeneous  sites  (see  below  on 
RDA)  and  distributed  database  management.  Also  needed  are  tools  for  the  support  of  object- 
oriented  data  management,  such  as  triggers,  assertions,  user-defined  types,  domain  and  table 
hierarchies,  and  stored  procedures.  While  the  scope  of  SQL3  (whose  standard  is  expected  to  be 
agreed  in  1995)  is  not  yet  defined,  it  is  expected  to  support  some  of  these  requirements. 

Distributed  database  access  is  supported  by  Remote  Data  Access,  ISO  9579.  RDA  is  used 
to  establish  a  remote  connection  between  an  RDA  client,  acting  on  behalf  of  an  application 
program,  and  an  RDA  server,  interfacing  to  a  process  that  controls  data  transfers  to  and  from  a 
database.  The  goal  is  to  promote  the  interconnection  of  applications  with  database  systems  within 
heterogeneous  environments,  with  emphasis  on  an  SQL  server  interface  that  can  provide 
interoperability  between  different  SQL  servers.  The  client/server  approach  of  RDA  is  one  of 
several  architectures  for  remote  access;  others  may  emerge  in  data  management  standards.  RDA  as 
yet  only  specifies  the  service  and  protocol  between  a  single  client  and  a  single  server — it  does  not 
currently  specify  distributed  database  access,  nor  does  it  support  stored  database  procedures. 

The  US  DoD  has  embarked  on  an  ambitious  program  to  centralize  data  administration  and 
to  define  and  adopt  DoD- wide  standard  data  elements.  DoD  instructions  and  procedures  have  bear 
prepared,  but  most  are  as  yet  only  in  draft  form.  A  DoD  data  repository  capability  has  been 
created,  but  to  date,  only  a  few  model -derived  prime  words  and  data  elements  have  been  approved. 
Development  of  data  models  (e.g.,  using  the  DoD-mandated  IDEF  language)  for  information 
systems  has  only  just  begun. 
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7.  DATA  INTERCHANGE  SERVICE  STANDARDS 

Data  interchange  services  transfer  data  that  represent 
abstract  objects  such  as  military  orders,  reports,  research 
documents,  graphical  items  (e.g.,  maps  and  overlays,  symbolic 
graphical  data  that  might  be  produced  by  a  simulation),  and  raw 
video  (e.g.,  television  images).  Data  interchange  services  also 
address  product  descriptions.  An  overview  of  the  status  of 
standards  for  data  interchange  services  is  given  in  Table  9. 

7.1  Document  Exchange 

This  section  summarizes  standards  for  office  document 
interchange  architectures  and  formats. 

7.1.1  Office  Document  Architecture  (ODA) 
and  Interchange  Format  (ODIF) 

Like  any  object  in  the  object-oriented  world,  a  document 
contains  information  relating  to  its  structure  and  content.  A 
document  architecture  is  a  set  of  rules  for  defining  the  structure 
and  representation  of  a  document  It  consists  of  a  structural 
model  and  a  descriptive  representation.  The  structural  model 
describes  the  structural  elements  of  a  document  and  the 
relationships  among  these  elements.  The  descriptive 
representation  describes  how  the  structural  elements  are 
represented  by  attributes. 

A  content  architecture  is  different  from  a  document 
architecture.  When  a  document  content  is  thought  of  as 
partitioned  into  content  portions,  a  content  architecture  defines 
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rules  for  positioning  content  portions  within  a  document  For  example,  it  specifies  the  nature  of 
the  content  the  presentation  attributes,  the  coding  methods,  the  control  functions  that  can  be 
applied  to  the  content  elements  within  a  content  portion,  and  the  content  positioning  rules.  Since  a 
document  may  contain  mixed  contents  (e.g.,  text  and  graphics),  different  content  portions  with 
different  content  architectures  can  coexist  within  a  document  So  far,  three  different  content 


architectures  have  been  defined  by  the  Office  Document  Architecture  (ODA)  standard.  They  are: 

•  Character  Content  Architecture — supports  the  character  repertoire  defined  in  ISO  6937 
( Coded  Character  Sets  for  Text  Communication )  and  other  character  sets  as  long  as 
they  are  defined  according  to  the  rules  of  ISO  2022  ( ISO  7-bit  and  8-bit  Coded 
Character  Sets  -  Code  Extension  Techniques). 

•  Raster  Graphics  Content  Architecture — supports  raster  graphics,  which  represent 
images  as  pixels  or,  in  ODA  terms,  pels  (picture  elements). 


•  Geometric  Graphics  Content  Architecture— supports  a  content  type  consisting  of  a 
series  of  geometric  constructs  such  as  point,  lines,  arcs,  polygons,  etc.  The  geometric 
graphics  in  ODA  are  based  on  ISO  8632  ( Computer  Graphics  Metafile  for  the  Storage 
and  Transfer  of  Picture  Description  Information). 


Future  versions  of  ODA  standard  may  include  content  architectures  for  sound,  speech,  and  three 
dimensional  images.  [Ref.  Tang  1992] 


ODA  (ISO  8613)  was  originally  designed  for  the  interchange  of  office  documents  between 
different  word  processors.  The  equivalent  ITU-TS  Recommendations  are  the  T.410  series  (see 
end  of  Appendix  E).  ODA  describes  a  document  in  terms  of  its  logical  structure  or  its  layout 
structure  or  both  together.  The  ODA  standard  is  divided  into  several  parts: 

•  ISO  8613-1  (Part  1),  Part  1:  Introduction  and  General  Principles 

AM  1,  Document  Application  Profile  Proforma  Notation 

AM  2,  Conformance  Testing  Methodology 

•  ISO  8613-2  (Part  2),  Document  Structures 

PDAD  1,  Formal  Specification  of  ODA  Document  Structures 

•  DIS  8613-3  (Part  3),  Abstract  Interface  for  Manipulation  of  ODA  Documents , 
April  1993 

•  ISO  8613-4  (Part  4),  Document  Profile 

•  ISO  8613-5  (Part  5 ),0ffice  Document  Interchange  Format  ( ODIF) 

•  ISO  8613-6  (Part  6),  Character  Content  Architectures 


•  ISO  8613-7  (Part  7),  Raster  Graphics  Content  Architectures 

•  ISO  8613-8  (Part  8),  Geometric  Graphics  Content  Architectures 

DAD1,  Tiled  Raster  Graphics 
-  DAM  2.2,  Color 

DAD  3,  Alternative  Representation 
DAD  4,  Security 
DAM  5.2,  Streams 
DAD  6,  Styles 

PDAM  10,  ODA  External  References  and  Document  Fragments 

•  CD  8613-9  (Part  9),  Audio  Content  Architectures 

•  ISQ/IEC  8613-10  (Part  10),  Formal  Specifications 

AM  1,  Formal  Specification  of  the  Document  Profile 

AM  2,  Formal  Specification  of  the  Raster  Graphics  Content  Architectures 

AM  3,  Formal  Specification  of  ODA  Character  Content  Architectures,  1992 
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AM  4,  Formal  Specification  ofODA  Geometric  Graphics  Content  Architectures, 
1992 

AM  5,  Formal  Specification  of  the  Defaulting  Mechanism  for  Defaultable 
Attributes,  1993. 

•  CD  8613-11  (Part  1 1),  ODA  Spreadsheet,  April  1993 

•  DIS  8613-12  (Pan  12),  ODA  Identification  of  Document  Fragments,  April  1993. 

Pan  3  of  ODA  specifies  a  second  method  of  representation  and  interchange,  using  the 
Office  Document  Language  (ODL)  and  the  Standard  Generalized  Markup  Language  (SGML) 
Document  Interchange  Format  (SDIF).  ODL  is  an  application  of  SGML,  and  may  be  used  to 
represent  a  document  structure  in  accordance  with  ODA  in  SGML.  (SGML  is  discussed  in 
Section  7.1.2  below.) 

In  1993,  ISO  adopted  TR  10183-1,  Text  and  Office  Systems  -  ODA  and  Interchange 
Format  -  Technical  Report  on  ISO  8613  Implementation  Testing. 

ISO  8613  is  being  adopted  as  an  American  National  Standard  as  well.  ANSI  X3V1,  Text: 
Office  and  Publishing  Systems,  plans  to  produce  multiple  part  addenda  that  will  provide  extensions 
to  an  ANSI  standard  that  will  remain  consistent  with  the  ISO  8613  standard.  [Ref.  X3  1991]  The 
following  describes  this  new  work  [Ref.  OSN  1991k]: 

•  Revision  accountancy  consists  of  a  collection  of  several  revisions  of  a  document, 
possible  including  some  additional  information  as  to  the  status  and  rational  for  a 
revision  and  its  author. 

•  Annotations  may  or  may  not  form  a  permanent  part  of  a  document,  but  they  may  use 
any  content  type. 

•  Automatic  content  generation  refers  to  generated  listings  including  table  of  contents, 
tables  of  figures,  and  illustrations;  indexes  and  glossaries;  cross  references;  and 
copying  of  body  material  into  executive  summaries  and  outlines. 

•  ODA  business  charting  includes  the  ability  to  derive  a  business  graphic  from  tabular, 
spreadsheet  or  other  data  in  the  document  or  referenced  by  the  document;  derive  part  of 
a  document  from  an  external  business  graphic;  and  include  a  business  graphic  in  a 
document  in  such  a  way  that  the  business  graphic  specific  processing  can  be 
performed  by  the  recipient 

•  Hypermedia  structures  allow  an  originator  to  be  able  to  pass  to  a  recipient  the  intention 
that  the  recipient  can  follow  one  or  more  routes  through  the  logical  structure  with 
associated  control  of  the  presentation  of  an  ODA  document 

•  The  ODA  audio  content  architecture  (Part  9)  will  define  a  content  architecture  for  voice 
and  other  audio  information.  It  will  use  pre-existing  or  developing  coding  standards 
for  audio.  Audio  content  which  may  be  used  for  annotation  or  other  purposes  within 
a  document,  has  a  close  relationship  with  time  synchronization  and  annotation 
extensions  for  the  ODA  document  processing  work. 

The  Profile  Alignment  Group  for  ODA  (PAGODA)  has  been  formed  from  the  three  special 
interest  groups  (SIGs)  and  expert  groups  (EGs)  from  the  three  regional  OSI  workshops  (see  also 
Section  16.1.1):  Asia/Oceania  Workshop  (AOW)  ODA  SIG,  EWOS  ODA  EG,  and  the  NIST 
ODA  SIG.  PAGODA  is  developing  ODA  profiles  based  on  ISO  8613,  Office  Document 
Architecture  (ODA)  and  Interchange  Format  (ODIF).  The  Office  Document  Format  (FOD) 
provides  for  two  types  of  structure  in  its  proposed  taxonomy  [Ref.  SGFS  1989]: 

•  Hierarchically  related  based  on  increasing  complexity  and  functionality  (simple, 
enhanced,  and  extended  document  structures).  The  simple  document  structure  is 
intended  to  address  the  general  requirements  of  current  word  processing  applications. 
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The  enhanced  document  structure  is  intended  to  address  the  general  requirements  of 
emerging  word  processing  applications  that  have  been  enhanced  over  current 
applications.  Tlie  extended  document  structure  would  address  the  general 
requirements  of  emerging  personal  publishing  and  document  processing  applications. 

•  Content  architectures  for  various  combinations  of  character,  raster  graphics,  and 
geometric  graphics  content  architectures. 

Profiles  that  have  achieved  International  Standardization  Profile  (ISP)  status  (see 
Section  16.1.2.4)  include  the  following  [Ref.  OSN  1991c]: 

•  FOD1 1  (ISP  10610-1),  Office  Document  Format  Profile  for  the  Interchange  of  Basic 
Functional  Character  Content  Documents  in  Processable  and  Formatted  Forms  - 
Part  1:  Document  Application  Profile  ( DAP ),  April  1992 

•  FOD112  (pDISP  12064-1),  Open  Document  Format:  Image  Applications  -  Simple 
Document  Structure  -  Raster  Graphics  Content  Architecture,  Part  1:  FOD  112, 
Document  Applications  Profile,  August  1993  (balloting  ended  December  1993) 

•  FOD26  (ISP  11181-1),  Office  Document  Format  Profile  for  the  Interchange  of 
Enhanced  Function  Mixed  Content  Documents  in  Processable  and  Formatted  Forms  - 
Part  1:  Document  Application  Profile  (DAP),  April  1992 

•  FOD36  (ISP  11182-1),  Office  Document  Format  Profile  for  the  Interchange  of 
Extended  Function  Mixed  Content  Documents  in  Processable  and  Formatted  Forms  - 
Parti:  Document  Application  Profile  (DAP),  April  1992. 

Although  there  is  no  strong  user  demand  for  ODA  products,  predictions  are  that  over  the 
next  5  years  ODA  has  the  potential  to  satisfy  growing  demand  for  standards-based  document 
management,  particularly  interchange.  Three  types  of  ODA  products  are  available: 

•  ODA  toolkits — intended  to  enable  ODA  conversion  facilities  to  be  built  into  products 
and  systems  with  minimum  effort 

•  Converters — extensions  to  existing  products  to  allow  them  to  take  part  in  ODA 
document  interchange 

•  Native  products — applications  that  implement  document  processing  functions  that 
conform  to  ODA  standards. 

Six  major  international  computer  companies  formed  the  Open  Document  Architecture 
Consortium  (ODAC)  to  develop  a  toolkit  of  software  that  conforms  to  the  ISO  ODA  standard.  The 
companies  are  Digital,  ICL,  Siemens  Nixdorf  Information  Systems,  Group  Bull,  IBM,  and 
Unisys.  The  toolkit  was  expected  to  be  available  in  1993  [Ref.  OSN  1991b].  In  addition,  Apple 
Europe  has  made  available  an  ODA  toolkit  called  WOPODA. 

Bull,  Siemens-Nixdorf,  and  Xerox  offer  ODA  converters  as  part  of  their  more 
comprehensive  office  systems  products.  Beta  test  versions  of  word  processor  converters  and 
native  ODA  editors  are  in  use  on  personal  computers  and  the  Apple  Macintosh. 

ODA  has  been  the  subject  of  visible  interworking  demonstrations  both  in  Japan  and 
Europe.  Cooperative  activity  in  Europe  has  included  the  PODA  (piloting  ODA)  project  that,  in 
1990,  demonstrated  the  interchange  of  integrated  text  and  graphics  documents  between  participants 
systems  using  X.400  electronic  messaging.  Moreover,  IBM  recently  announced  that  it  will  adopt 
the  ODA  standard  instead  of  the  revised  form  of  its  own  Mixed  Object  Document  Content 
Architecture  (MO.DCA).  Microsoft  has  also  declared  its  intention  to  support  ODA  and  has  an  ODA 
Manager  based  around  its  Microsoft  Word  product  [Ref.  OSN  1991d] 
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7.1.2  Standard  Generalized  Markup  Language  (SGML) 

SGML  formalizes  document  markup,  making  the  document  system  and  processing 
independent  It  is  an  architecture-free  and  application-free  language  for  managing  structures  and  is 
designed  for  full  multimedia  database  publishing.  SGML  is  a  meta-language,  providing  the  rules 
for  designing  and  applying  a  system  of  markup  tags  rather  than  the  specific  set  of  tags.  As  noted 
above,  ODL  is  a  set  of  rules  in  ODA  for  using  SGML  to  represent  documents.  The  SGML 
standards  are: 

•  ISO  8879,  Standard  Generalized  Markup  Language  ( SGML)  (FIPS  152) 

•  TR  9573,  SGML  Support  Facilities — Techniques  for  Using  SGML,  which  is  under 
revision  to  include  the  following  parts,  all  of  which  are  in  WD  status  except  Parts  1 1 
and  12,  which  have  reached  TR  status: 

Part  1:  SGML  Tutorial 
Part  2:  Basic  Technique 

Part  3:  Advanced  Techniques  -  Using  LINK  and  CONCUR 

Part  4:  Advanced  Techniques  -  Using  SHORTREF  to  Indicate  Markup 

Part  5:  Using  Non-Latin  Alphabets 

Part  6:  Referencing  and  Synchronization 

Part  7:  Mathematics  and  Chemistry 

Part  8:  Tables 

Part  9:  Using  SGML  for  Computer  to  Computer  Interchange 

Part  10:  Designing  Applications  for  Database  Interfacing 

Part  1 1:  Application  at  ISO  Central  Secretariat  for  International  Standards  and 

Technical  Reports:  1991 

Part  12:  Public  Entity  Sets  for  General  and  Publishing  Symbols:  1991 

Part  13:  Public  Entity  Sets  for  Mathematics  and  Sciences 

Part  14:  Public  Entity  Sets  for  Latin  Based  Alphabets 

Part  1 5:  Public  Entity  Sets  for  Non-Latin  Based  Alphabets 

Part  16:  Public  Entity  Sets  for  Ideograms 

•  ISO  9069,  SGML  Support  Facilities — SGML  Document  Interchange  Format 

•  ISO  9070,  SGML  Support  Facilities— Registration  Procedures  for  Public  Text  Owner 
Identifiers 

•  TR  10037,  SGML  and  Text-Entry  Systems — Guidelines  for  SGML  Syntax-Directed 
Editing  Systems. 

X3. 190- 1992,  Conformance  Testing  for  SGML  addresses  the  construction  and  use  of  test 
suites  for  verifying  conformance  of  SGML  systems  (see  also  Section  12.2).  Its  provisions  assist 
those  who  build  test  suites,  those  who  build  SGML  systems  to  be  evaluated  by  such  suites,  and 
those  who  examine  an  SGML  system's  performance  on  a  test  suite  as  part  of  the  process  of 
selecting  an  SGML  tool.  [Ref.  X3  1991a] 

Three  standards  related  to  SGML  are: 

•  ISO  10179,  Document  Style  Segmentation  and  Specification  Language  (DSSSL), 
June  1991 

•  DIS  10180,  Standard  Page  Description  Language  (SPDL),  March  1991  (a  FIPS  is 
planned  by  NIST) 

•  M1L-M-28001B,  Markup  Requirements  and  Generic  Style  Specification  for  Electronic 
Printed  Output  and  Exchange  of  Text,  June  1993. 
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Some  people  believe  that  these  standards,  when  used  with  SGML  and  viewed  as  a  group,  will 
comprise  a  much  mote  comprehensive  information  management  architecture  than  that  envisioned 
by  ODA.  [Ref.  Terrell  1990] 

HyTime.  SGML  is  also  being  extended  to  deal  with  hypermedia/time-based  document 
interchange.  The  HyTime  standard,  Hypermedia/Time-based  Structuring  Language  (HyTime), 
was  developed  by  ANSI  X3V1.8M  (Project  749-D)  and  ISO  (ISO  10744).  It  is  a  notation  to 
describe  hypermedia.  HyTime  is  a  collection  of  abstract  semantic  constructs  associated  with 
syntactic  conventions.  It  allows  hyperdocument  interoperability  (1)  without  standardizing 
multimedia  objects,  their  notations,  their  modifiers,  the  effects  of  those  modifiers  on  them,  and  the 
semantics  of  link  types;  and  (2)  without  requiring  existing  documents  to  be  recast  in  order  to  make 
their  contents  linkable  to  HyTime  documents.  HyTime-compliant  documents  can  allow  HyTime- 
cognizant  software  to  browse,  render,  format,  and  query  them  even  if  that  software  is  not  able  to 
understand  or  render  its  multimedia  objects.  If  the  notation  of  an  object  is  uninterpretable  because 
no  interpreting  system  is  locally  available  for  it,  the  render  can  still  incorporate  some  form  of 
blankness,  e.g.,  darkness,  silence,  or  an  appropriate  error  message,  so  that  the  space  and  time 
relationships  of  the  rendered  and  unrenderable  objects  are  preserved.  [Ref.  Newcomb  cl 991] 

HyTime  is  gaining  worldwide  acceptance.  The  US  DoD  has  plans  to  use  HyTime  as  the 
basis  for  its  Interactive  Electronic  Technical  Manuals.  The  European  Community  has  approved 
HyTime  for  official  projects  and  has  just  let  a  contract  to  encode  their  central  database  for  official 
travel  in  HyTime.  [Ref.  CGA  1992] 

EMPM.  Object-oriented  methods  are  at  the  heart  of  another  similar  standards  effort,  led 
by  the  Multimedia  and  Hypermedia  Information  Coding  Experts  Group  (MHEG).  [Ref.  Fox  1991] 
The  Electronic  Manuscript  Preparation  and  Markup  (EMPM)  specification,  ANSI/NISO  Z39.59- 
1988,  is  an  architecture  encoded  in  SGML  suitable  for  the  interchange  of  the  logical  structure  of 
books,  articles,  and  serials.  Developed  by  the  Association  of  American  Publishers  (AAP),  it 
provides  a  high  level  language  for  describing  these  logical  structures  but  offers  little  assistance  with 
layout  and  presentation  style  issues.  [Ref.  APP  1992]. 

CALS.  SGML  has  been  chosen  by  the  US  DoD  as  the  documentation  standard  for  its 
Continuous  Acquisition  and  Life  Cycle  Support  (formerly  Computer  Acquisitions  and  Logistics 
Support)  (CALS)  strategy.  This  strategy  is  designed  to  take  defense  information  from  its  current 
paper  form  to  a  totally  electronic  mode  over  the  next  decade.  MIL-M-28001B  establishes  the 
requirements  for  the  digital  data  form  of  technical  publications.  Data  prepared  in  conformance  to 
these  requirements  will  facilitate  the  automated  preparation,  storage,  retrieval,  exchange,  and 
processing  of  technical  documents  from  heterogeneous  data  sources.  The  requirements  set  forth 
by  this  specification  include; 

•  Procedures  and  symbology  for  markup  of  unformatted  text  in  accordance  with  this 
specific  application  of  SGML 

•  SGML-compatible  codes  that  will  conform  a  technical  publication  to  specific  format 
requirements 

•  Output  control  codes  that  will  conform  automated  document  processing  functions  to  a 
uniform  structure. 

MIL-M-28001B  establishes  the  requirements  for  the  digital  forms  of  all  US  DoD  technical 
publications  using  SGML.  Data  files  satisfying  the  requirements  of  this  specification  will  be  one 
of  two  types:  Type  I  -  MIL-M-38784B  conforming  technical  manuals  and  Type  II  -  technical 
manuals  conforming  to  other  military  specifications.  Documents  prepared  in  accordance  with  MIL- 
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M-38784B  and  MIL-M-28001B  must  conform  to  the  document  type  definition  (DID)  defined  in 
Appendix  A  and  the  output  specification  in  Appendix  C  of  MIL-M-2800 1 B .  The  DTD  and  output 
specification  for  a  MIL-M-38784B  conforming  manual  do  not  have  to  be  delivered  with  the  tagged 
text  Technical  manuals  conforming  to  other  military  specifications  may  develop  their  own  DTD 
but  must  use  only  those  tags  in  the  baseline  tag  set  defined  in  Appendix  B  of  MIL-M-28001B.  In 
this  case,  the  DTD  must  be  delivered  with  the  publication  along  with  a  compatible  output 
specification. 

MIL-M-2800 IB  addresses  the  five  steps  in  the  publication  preparation  process: 

(1)  Creating  a  DTD  for  publication  control 

(2)  Authoring  the  publication  and  inserting  SGML  markup  tags 

(3)  Verifying  the  syntax  according  to  the  rules  of  SGML 

(4)  Using  the  output  specification  to  compose  the  document  so  that  produced  copy 
corresponds  to  the  proper  formal  and  style 

(5)  Generating  a  text  presentation  metafile  in  SPDL  to  drive  the  display  device. 

The  heart  of  MDL-M-28001B  is  found  in  its  appendixes.  Appendix  A  specifies  the  role 
played  by  the  DTD  in  an  SGML  implementation;  a  general  description  of  DTD  structure  and 
content;  the  specific  DTDs  available  for  use  in  authoring,  validating,  and  verifying  an  SGML- 
tagged  technical  document;  and  procedures  for  DTD  development  The  appendix  introduction 
provides  an  overview  of  the  concepts  behind  the  SGML  standard,  a  brief  tutorial  on  reading  an 
SGML  DTD,  guidelines  for  using  SGML  tags,  and  DoD's  SGML  declaration.  Two  DTDs  are  also 
presented  in  Appendix  A.  This  first  DTD  is  for  use  when  preparing  a  document  that  conforms 
with  MIL-M-38784B.  The  second  uses  the  same  elements  as  the  first  DTD  with  the  addition  of 
more  subordinate  paragraphs  and  steps.  This  DTD  may  be  used  for  MIL-M-38784B  non- 
conforming  documents  or  as  a  model  for  the  development  of  a  more  appropriate  DTD.  Both  DTDs 
allow  for  four  types  of  non-SGML  data:  IGES  data,  CGM  data,  ITU-TS  Group  4  data,  and 
system-generated  data. 

Appendix  B  of  MIL-M-2800 IB  contains  an  alphabetical  listing  of  all  elements  contained  in 
the  DTDs  presented  in  Appendix  A.  Appendix  C  is  a  stand-alone  document  It  includes  a 
document  output  specification  (format  and  style  guide)  to  be  used  for  all  applications  of  this 
specification.  Although  the  format  default  values  are  set  according  to  MIL-M-38784B,  the  values 
may  be  tailored  to  satisfy  other  format  requirements.  The  appendix  also  provides  an  example  of  an 
SGML-coded  source  file  and  the  composed  sample  document  produced  from  the  marked  up  file. 

The  US  DoD  CALS  Digital  Standards  Office  recently  established  the  CALS  SGML  Library 
(CSL)  which  will  be  the  DoD  holding  place  for  all  registered  and  approved  SGML  tags  used  in 
DTDs  for  functional  specifications  and  other  DoD  CALS  documentation  using  SGML  applications. 
The  CSL  will  also  contain  the  official  DTDs  for  military  specifications  as  well  as  other  related 
SGML  data  not  yet  defined.  Therefore,  there  is  no  longer  a  need  to  have  the  MIL-M-38784B  DTD 
and  all  the  subset  DTDs  from  Appendix  D,  the  library  entities  from  Appendix  C,  or  the  Baseline 
Tag  Set  Table  residing  in  MIL-M-28001.  This  will  considerably  streamline  MIL-M-2800 1.  [Ref. 
Barlow  Report  n.d.] 

CALS,  since  it  is  an  application-specific  architecture  oriented  to  technical  weapons  systems 
support  documentation,  may  not  be  applicable  to  all  of  the  other  types  of  information  that  a  generic 
information  system  comprises. 
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Relation  of  SGML  to  ODA.  There  is  an  incorrect  perception  that  ODA  and  SGML  are 
competing  standards.  In  fact,  ODA  is  a  generic  interchange  architecture  that  uses  SGML  as  one  of 
its  interchange  formats.  The  other  interchange  format,  ODIF,  is  specifically  of  use  in  an  OSI 
environment  because  it  uses  ASN.  1.  However,  both  standards  exist  in  the  application  layer  of  the 
OSI.  Although  CALS  has  selected  SGML,  it  has  left  the  door  open  to  ODIF  as  well.  The  NIST 
assessment  is  that  both  ODA/ODIF  and  SGML  enjoy  an  average  level  of  consensus,  and  neither 
has  much  product  availability  or  de  facto  usage.  However,  it  evaluates  ODA/ODIF  as  being  more 
complete  than  SGML,  but  rates  SGML  as  being  significantly  more  stable  and  mature  than 
ODA/ODIF.  [Ref.  APP  1991,  p.  35] 

However,  SGML  and  ODA  are  incompatible  in  the  sense  that  most  documents  encoded 
using  SGML  cannot  be  used  directly  in  an  ODA-based  system,  and  vice  versa.  Translations 
programs  are  therefore  necessary  if  both  standards  are  to  be  used.  [Ref.  Nicholas  1992] 

7.1.3  Distributed  Office  Applications  Model  (DO AM) 

The  Distributed  Office  Application  Model  (DO AM,  ISO  10031)  was  established  to  provide 
a  set  of  common  principles  to  which  all  Distributed  Office  Application  (DOA)  standards  must 
adhere.  The  two  parts  of  this  standard.  General  Model  and  Referenced  Data  Transfer  (see 
Section  7.1.7)  do  not  contain  any  implementable  protocols;  they  are  limited  to  the  description  of 
models  and  tools  to  be  used  by  DOA  standards  developers. 

An  important  feature  of  the  DO  AM  is  the  client-server  model,  which  allows  oik  part  of  an 
application  to  be  implemented  in  a  "client"  machine  and  another  part  to  be  implemented  in  a 
"server”  machine.  This  possibility  of  splitting  an  application  allows  certain  central  resources,  such 
as  a  large  database  or  an  expensive  laser  printer  to  be  shared  among  a  number  of  users  from  their 
workstations. 

DOA  consists  of  the  DOA  model  (DO AM)  and  two  specific  DO  As:  Document  Filing  and 
Retrieval  (DFR,  ISO  10166;  see  Section  7.1.6)  and  Document  Printing  Application  (DPA, 
DIS  10175).  The  DOAM  (ISO  10031)  addresses  the  general  model,  design  guidelines  for  the 
peer-to-peer  (Application  Layer)  protocol,  and  Referenced  Data  Transfer  ( RDT ).  Use  of  ROSE  is 
mandatory  in  DOAM.  The  DOAM  guidelines  are  used  to  define  DOA  objects  (e.g.,  documents), 
together  with  object  attributes  and  criteria  for  filtering  those  objects.  The  DOAM  guidelines 
identify  a  set  of  abstract  operations  such  as  List,  Read,  Write,  Modify,  Copy,  Move,  Search, 
Create,  Delete,  Reserve,  Unreserve,  Notify,  and  Abandon.  RDT  is  the  mechanism  used  to 
perform  transfer  of  objects.  RDT  was  developed  to  permit  “small”  systems  (e.g.,  workstations)  to 
handle  “large”  objects,  such  as  moving  an  object  from  a  document  store  to  a  print  service.  DFR 
defines  the  structure  of  a  document  store  and  an  associated  access  protocol.  DPA  defines  an  access 
protocol  for  print  services.  DOA  is  being  developed  by  SC18/WG1  [Ref.  SC21  N  3930  1989]. 
SC  18  merged  the  DOA  and  messaging  work  into  one  working  group  (WG4)  to  produce  better 
cooperation  between  the  two  areas.  [Ref.  OSN  1991k] 

A  new  work  item  for  SC18/WG4  (Special  Working  Group  on  DOA)  is  Engagement 
Scheduling  and  Recording  Application  (ESRA)  with  the  DOAM,  August  1993  [SC21  N  8255].  It 
will  provide  a  specification  of  a  service  and  protocol  that  supports  scheduling  and  recording  of 
engagement  entries  on  multiple  calendars.  Part  1,  Abstract  Service  Definition  and  Procedures,  was 
expected  to  have  CD  status  in  1993,  DIS  status  June  1994,  and  IS  status  December  1995. 


Chapter  7 


100 

UNCLASSIFIED 


Data  Interchange 


UNCLASSIFIED 

7.1.4  Electronic  Data  Interchange  (EDI) 

EDI32  provides  for  a  standardized  exchange  of  data  between  systems  by  a  wide  range  of 
means,  including  exchange  of  magnetic  tapes  and  the  transmission  of  data  by  Telex.  EDI  is 
intended  to  enable  data  to  be  interchanged  without  networking  and  is  used  mainly  for 
interorganization  communication  where  internetworking  may  be  undesirable  (internetworking  is  a 
primary  feature  of  OSI). 

It  is  important  to  note  that  although  the  standard  focuses  on  the  structure  of  an  EDI 
document,  it  leaves  the  communication  community  to  develop  a  solution  for  the  transfer  of  the 
document,  using,  for  example,  the  OSI  international  communication  standards  (see  Chapter  9),  to 
support  the  exchange  of  an  international  interchange  format  The  benefits  of  applying  OSI  to  EDI 
include  reduced  clerical  overhead  and  faster  transmission,  which  imply  lower  cost  and  better 
service  to  the  customers.  [Ref.  Tang  1992]. 

EDI  Standards.  Prior  to  1985,  there  were  two  world-wide  EDI  standards,  UN- 
TDI/GTDI  in  Europe  and  ANSI  X12  (An  Introduction  to  EDI,  July  1987)  in  North  America.  In 
1988,  the  United  Nations  Economic  Commission  of  Europe  (UN  ECE)  published  the  standard  EDI 
for  Administration,  Commerce,  and  Transport  (EDIFACT),  designed  to  be  a  single  standard  for 
both  communities.  TC  154  of  ISO,  which  deals  with  trade  and  commerce,  ratified  the  EDIFACT 
syntax  and  trade  dictionary,  and  produced  two  ISO  documents:  ISO  9735  and  ISO  7372.  Since 
then,  EDIFACT  has  been  widely  accepted  as  a  worldwide  de  facto  standard.  EDIFACT  is  based 
on  ISO  646  encoding  [7  bits  per  character — ASN.l  Basic  Encoding  Rules  (see  Section  9.10.2) 
use  the  full  range  of  8  bits  in  each  octet].  A  large  number  of  standard  messages  have  been 
developed  based  on  EDIFACT,  and  the  EDIFACT  has  been  endorsed  by  many  standards  bodies 
and  user  groups. 

Another  standard,  TRADACOMS,  has  been  developed  for  use  in  the  United  Kingdom, 
based  on  the  UN-GTDI  syntax.  TRADACOMS  is  now  in  wide  use  in  the  United  Kingdom  and 
currently  enjoys  the  status  of  de  facto  UK  standard.  However,  a  recent  notice  [Ref.  CCTA  1991a] 
issued  by  the  CCTA  in  the  United  Kingdom  states  that  "departments  should  refrain  from  its 
(TRADACOMS')  use"  and  invites  departments  and  agencies  to  adopt  EDIFACT  as  the  EDI 
standard.  CCTA's  UK  GOSIP  Version  4  provides  up-to-date  guidance  on  the  use  of  EDIFACT. 

EDIFACT  provides  data  structure  and  content  standards  for  developing  messages  for  use 
by  importers,  exporters,  transportation  firms,  financial  institutions,  ports,  customs,  and  other 
business  and  administrative  activities  (e.g.,  insurance,  tourism,  construction).  EDIFACT  was 
developed  by  the  UN  working  party  on  Facilitation  of  International  Trade  Procedures  to  ensure 
there  is  only  one  worldwide  standard  for  EDL  EDIFACT  is  ISO  9735  and  uses  the  international 
standard  Trade  Data  Element  Directory  (ISO  7372)  [Ref.  SC21  N  3885  1989].  ANSI  X12  guides, 
stimulates,  and  promotes  the  development  and  use  of  the  EDIFACT  standards  in  the  United  States 
and  Canada,  but  EDIFACT  is  still  not  aligned  with  ANSI  X12.  The  ANSI  X12  Secretariat  has 
noted  that  differences  in  syntax  control  segments,  data  segments,  and  data  elements  continue  to 
exist  between  EDIFACT  and  the  X12  standard  for  EDI  [Ref.  DISA  1990].  X12  plans  to  align 
with  EDIFACT  in  1997,  after  publication  of  Version  4  of  the  X12  standards  in  1994. 
[Ref.  Komfeld  1990]  FIPS  161  (EDI)  was  published  29  March  1991. 


32  The  abbreviation  EDI  is  frequently  written  in  all-lower-case  learn:  edi. 
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Use  of  EDI  In  MHS  and  FTAM.  Either  the  Message  Handling  System  (MHS) 
standard  (ITU-TS  X.400)  or  the  File  Transfer,  Access,  and  Manipulation  (FTAM)  standard 
(ISO  8571)  can  be  used  to  transfer  an  EDI  document  In  particular,  the  security  features  of  the 
1988  version  of  the  MHS  standard  are  of  great  importance  to  the  business  world.  Therefore  in 
1990,  CCm  brought  together  MHS  and  EDI,  and  produced  two  CCITT  Recommendations, 
namely,  F.435  and  X.435.  F.435  describes  the  MHS-EDI  messaging  service,  while  X.435 
describes  the  MHS-EDI  Messaging  System  in  more  depth.  The  framework  of  the  435  documents 
is  general  in  the  sense  that  it  uses  MHS  to  carry  not  only  EDIs  conforming  to  ED  IF  ACT,  but  also 
EDIs  conforming  to  TDCC,  ANSI  X12,  and  others.  It  is  robust  because  it  can  be  used  to  carry 
EDI  documents  of  different  formats  in  the  future. 

In  1991,  ITU-TS  published  X.435,  Message  Handling  Systems:  Electronic  Data 
Interchange  Messaging  System.  X.435  uses  a  new  User  Agent  protocol  called  PEDI  that  includes 
security  services  necessary  to  support  nonrepudiation.  The  ITU-TS  EDI  user  agent  allows  CALS 
formats  (e.g.,  US  MIL-STD-1840B,  CALS  Originator  File  Sets  and  Transfer)  to  be  supported  as 
body  parts.33 

In  May  1991,  SC21/WG5  proposed  an  EDDF ACT/FT  AM  Document  Type  (see  also  Section 
9.1 1.6)  in  an  attempt  to  merge  existing  FTAM  implementations  with  existing  EDI  systems  with  a 
minimum  of  change.  [Ref.  SC21  N  6224  1991] 

Use  of  EDI  in  CALS.  The  CALS  initiative  is  the  largest  and  best  known  of  the  EDI 
proponents.  CALS  required  full  compliance  to  EDI  standards  for  digital  delivery  of  technical 
information  and  interoperability  among  DoD  systems  beginning  in  January  1990.  Major 
applications  areas  are  automation  of  technical  manuals,  computer-assisted  design,  and  spares 
acquisition.  CALS  standards  include  EDI  for  data  interchange  file  management,  IGES  for 
engineering  drawings.  Standard  Generalized  Markup  Language  (SGML)  for  automated  publishing, 
and  CGM  for  technical  manual  illustrations.  The  standard  currently  being  used  for  raster  graphics 
representation  is  US  DoD-unique  (MIL-R-28002B  dated  14  December  1992). 

MEL-HDBK-59B,  Department  of  Defense  Computer-aided  Acquisition  and  Logistic 
Support  (CALS)  Program  Implementation  Guide  (dated  12  June  1993)  assists  weapon  system 
acquisition  managers  to  understand  when,  where,  and  how  to  apply  CALS  capabilities  efficiently 
to  support  their  information  interchange  and  access  requirements,  and  how  to  define  their 
functional  requirements  for  integration  of  the  contractor  processes  (such  as  reliability  and 
maintainability  analysis)  that  cream  and  use  the  information. 

MIL- STD-974,  Contractor  Integrated  Technical  Information  Service  ( CTTIS ),  Functional 
Requirements  (Fall  1993)  implements  the  DoD’s  new  CALS  acquisition  policy,  which  gives 
preference  to  contractor  information  services  and  on-line  access  instead  of  data  deliverables.  While 
the  other  CALS  standards  address  the  transition  from  paper  data  deliverable  to  digital  data 
deliverables,  MIL-STD-974,  addresses  how  DoD  will  buy  information  services.  It  defines  things 
a  contractor  must  do,  such  as  planning,  analysis,  and  submitting  proposals,  and  things  the  service 
must  do,  such  as  managing  data,  and  providing  access  to  the  data  tailored  to  meet  a  government 
Concept  of  Operations. 


33  The  Report  on  ITU-TS  Study  Group  7  Program  of  Work  and  Collaboration  with  SC  21,  SC21  N  7887,  June 
1993  lists  X.433  as  an  "Independent"  project  and  does  not  indicate  that  ISO  intends  to  adopt  this  standard. 
Likewise,  SD-10:  SC21/TTV-TS  Collaborative  Projects,  SC21  N  8083,  September  1993  does  not  list  it 
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MIL-ACQ-GUIDEA,  Acquisition  Guide  for  Implementation  of  Computer-aided 
Acquisition  and  Logistic  Support  (CALS),  provides  information  to  personnel  responsible  for  the 
acquisition  and  use  of  weapon  system  technical  data.  Its  purpose  is  to  assist  acquisition  managers 
in  making  the  transition  from  paper- intensive  processes  to  digital  data  delivery  and  access.  It  also 
supports  the  structuring  of  contract  requirements  to  achieve  integration  of  various  contractor 
automated  capabilities  for  design,  manufacturing,  and  logistic  support  [Ref.  CALS/CE  1992a] 

A  Tri-Service  Working  Group  produced  three  military  specifications  cm  Interactive 
Electronic  Technical  Manuals  (IETMs),  one  of  the  fastest  growing  areas  in  CALS  to  be  tested  and 
implemented.  They  are  [Ref.  CALS  1993]: 

•  MIL-M-87268,  IETMs:  General  Content,  Style  and  Format 

•  MIL-D- 87269,  Interchange  Formats  for  IETM  Databases 

•  MIL-Q-87270,  Requirements  for  Quality  Assurance  Programs  for  IETMs. 

Open-EDI.  The  ISO/IEC  JTC1  special  working  group  (SWGj  on  EDI  published  a  report 

on  the  Open-EDI  [JTC1  N 1384  May  1991]  conceptual  model  for  furthering  global  interoperability 
of  electronic  data  interchange.  The  "open-EDI"  model  (1)  describes  "business"  relationships 
among  participants  in  EDI  in  a  formal  way  and  (2)  facilitates  development  of  standards  and  tools 
supporting  this  description.  The  report  recommended  seven  new  work  item  proposals: 

•  Open-EDI  Reference  Model 

•  Business  Agreement  Services 

•  EDI  Support  Services 

•  Requirements  for  Amendment  and/or  Addition  of  Non-EDI- Specific  Standards 

•  Usage  Specifications  for  Non-EDI-Specific  Standards 

•  Requirements  for  Amendment  and/or  Addition  of  EDI-Relaled  Standards 

•  Usage  Specifications  for  EDI-Related  Standards. 

Moreover,  the  report  recommended  that  this  work  be  conducted  under  responsibility  of  a 
single  body.  Since  no  single  existing  subcommittee  had  a  scope  which  covers  all  aspects 
concerned,  the  JTC1/SWG-EDI  recommended  that  a  new  subcommittee  called  Open-EDI  be 
formed  to  take  responsibility  for  development  of  a  conceptual  model  for  EDI  and  of  associated 
standards,  and  for  furthering  global  interoperability  of  EDL  JTC1  disbanded  the  SWG-EDI  and 
resolved  to  establish  a  Working  Group  to  work  on  open-EDI  with  die  title,  scope,  and  program  of 
work  recommended  by  the  SWG-EDL  [Ref.  SC21  N  6530  1991] 

Consequently,  the  Inter-Agency  edi  Working  Group  (IAeG)  was  formed,  bringing  together 
representatives  from  the  UN,  ITU-TS,  and  JTC1.  The  October  1992  meeting  produced  a 
temporary  document  (IAeG  N  32  R2)  which  includes  proposals  for  discussion.  It  also  suggests  a 
matrix  of  technical  areas  subject  to  standardization  linked  to  the  organizations  who  produce 
standards  today,  and  proposes  a  new  distribution  of  work  in  these  areas.  [Ref.  SC21  N  7487 

1992] 

At  the  request  of  the  JTC1  WG3  open-EDI  group,  the  Special  Working  Group  on 
Modeling  Facilities  (SWG-MF)  (see  Section  6.2.5.3)  issued  tentative  working  definitions  and 
distinctions  between  the  meanings  of  the  terms  conceptual  schema  modelling  facility  (CSMF)  and 
data  modelling  facility  (DMF),  as  well  as  interim  guidelines  for  using  conceptual  modelling 
facilities,  and  for  specifying  standards.  These  definitions  are  contained  in  [Ref.  SC21  N  7542 

1993]  and  provided  in  Section  6.2.5.3. 
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lo  July  1993,  the  British  Standards  Institute  highlighted  [Ref.  DISC  1993a]  the  confusion 
created  by  multiple  stand&rds-making  bodies  for  EDL  These  include,  as  noted,  the  United  Nations 
and  its  Economic  Commission  for  Europe,  the  Simplified  Trade  Procedures  (SITPRO) 
organization  under  the  UK  DTI,  the  technical  committees  of  ISO  that  develop  bar  coding  and  other 
standards,  and  the  ISO/IEC  JTC1  that  develops  the  underlying  information  technology  standards. 
In  addition,  there  is  the  Western  European  EDIFACT  Board,  which  operates  on  behalf  of  the 
United  Nations,  a  CEN  ad  hoc  working  group  on  EDI,  and  a  CEN  working  group  on  CALS. 
Since  that  report,  EWOS  has  created  an  expert  group  focusing  on  EDL 

A  comprehensive  analysis  of  EDI  user  requirements  and  survey  of  current  activities  are 
provided  in  the  EWOS  Technical  Guide  on  EDI  [Ref.  ETG  30  1993].  Current  concerns  regarding 
EDI  are  the  data  transfer  aspects,  in  particular  the  interface  between  EDI  applications  and 
communications  protocols  in  an  open  systems  environment  (OSE).  The  EWOS  Expert  Group 
(EG)  on  EDI,  initiated  in  September  1993,  is  responsible  for  the  technical  work  of  EWOS  in  the 
area  of  EDL  including  communications  support  [Ref.  EWOS/T A/93/331  1993]  One  new  work 
item  proposal  for  the  EG-EDI  is.  Interactive  EDI  and  TP,  developing  TP  OSE  profiles  for  use  by 
EDI  applications  (target  date  is  September  1994).  Of  specific  concern  by  users  is  multiparty 
operation,  such  as  in  passenger  airline  reservations  and  cargo  reservation  systems.  A  parallel  new 
work  item  proposal  is  on  Profiling  Methodologies  for  Composite  EDI  Message  Structures,  in 
which  there  may  be  data  encoded  in  a  variety  of  standards  or  de  facto  specifications  that  need  to  be 
embedded  in  an  EDI  message  target  date  is  May  1995).  These  may  include  graphic  designs  and 
image-plus-character-based  information.  A  future  requirement  may  be  full-motion,  full-picture 
video. 

7.1.5  Document  Transfer  and  Manipulation  (DTAM) 

DTAM  is  being  developed  by  ITU-TS  SG8.  The  DTAM  protocols  are  designed  to  support 
interactive  as  well  as  store-to-stoie  real-time  end-to-end  communications.  They  are  also  suitable 
for  multimedia  applications.  Telematic  applications  are  currently  defined  within  the  integrated, 
modular  approach  based  on  ODA  (see  Section  7.1.1),  DTAM,  and  Document  Architecture 
Operations  (DAO,  ITU-TS  SG  VIII) .  The  telematic  applications  are  Group  4  Facsimile,  mixed 
mode,  processable  mode,  and  videotext  internetworking.  Each  telematic  application  consists  of 
equipment  characteristics,  document  characteristics  (selected  from  ODA),  operational 
characteristics  (optional,  selected  from  DAO),  and  communications  characteristics  (selected  from 
DTAM). 

DTAM  differs  from  FT  AM  in  that  the  standards  address  different  environments.  FT AM 
satisfies  requirements  for  the  transfer  of  files  between  different  file  systems,  including  retention  of 
generic  filing  information.  DTAM,  on  the  other  hand,  provides  facilities  for  the  storage, 
management,  and  retrieval  of  documents  in  an  integrated  office  application  environment 

Two  types  of  telematic  and  office  environment  applications  for  DTAM  are  being  developed 
by  ITU-TS  SG8  and  ISO  JTC1  SC  18:  conference  type  and  remote  document  handling.  A  service 
called  Remote  Open  Document  Editing  (RODE)  is  being  proposed  for  the  telematic  environment  to 
provide  real-time  remote  editing  for  commit  manipulation  through  use  of  ODA/DTAM.  RODE  is 
expected  to  fulfill  such  user  requirements  as  observing  changing  documents;  maintaining  identical 
documents  between  partners,  even  when  partners  have  different  presentations;  providing  speedy 
manipulations;  and  potentially  supporting  participation  of  more  than  three  partners.  Services  are 
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being  defined  to  enable  RODE  to  support  a  desk  top  conference  application  using  DFR  as  well  as 
RODE.  [Ref.  SC21  N  4342  1990] 

7.1.6  Document  File  and  Retrieval  .(DFR) 

DFR  (ISO  10166)  is  the  responsibility  of  ISO/IEC  JTC1  SC18/WG4.  DFR  is  one  of  the 
office  application  standards  defined  by  the  DO  AM  (see  Section  7.1.1)  and  shares  common 
mechanisms  with  Directory  services  and  MOTIS.  These  mechanisms  include  attribute  definition 
and  filtering  facilities,  and  they  use  the  Remote  Operations  Service  Element  (ROSE)  and  the 
Reliable  Transfer  Service  Element  (RTSE). 

DFR  also  supports  a  "version  management"  mechanism.  This  mechanism  allows  a 
document  to  be  declared  as  a  new  version  of  an  existing  document.  When  this  is  done,  a 
"previous-version"  attribute  points  to  the  previous  version  of  the  document,  and  the  previous 
version  correspondingly  receives  a  "next-version"  attribute,  thus  retaining  the  complete  evolution 
of  a  given  document  All  versions  of  a  document  contain  a  "version-root"  attribute  indicating  the 
first  version  of  the  document 

ISO  10166,  Document  File  and  Retrieval,  has  die  following  two  parts: 

•  ISO  10166-1  (Part  1):  Abstract  Service  Definition  and  Procedures,  1989 

•  ISO  10166-2  (Part  2):  Protocol  Specification,  1989. 

DFR  and  DTAM  both  handle  primarily  ODA  documents.  They  differ  in  that  DFR  is  not 
concerned  with  the  inner  content  of  a  document  whereas  DTAM  is  concerned  with  both  the  whole 
document  and  the  inner  content  of  the  document  Further,  DFR  provides  for  filing  and  retrieval  of 
(whole)  documents,  whereas  this  capability  is  not  supported  by  DTAM. 

DFR  differs  from  FT AM  in  that  filing  and  retrieval  of  documents  is  DFR's  single  specific 
office  application.  An  important  difference  between  these  two  standards  is  the  manner  in  which  a 
document  or  file  is  identified.  DFR  uses  a  "Unique  Permanent  Identifier"  that  remains  with  the 
object  for  its  lifetime.  FT AM  uniquely  identifies  its  objects  by  its  pathname  from  die  root  through 
the  directories  leading  to  it  In  FT AM,  if  the  contents  of  a  file  are  moved  to  another  directory,  the 
pathname  will  change.  Also,  there  is  no  analogy  in  FT  AM  of  DFR’s  version  control  mechanism. 

A  joint  meeting  between  SC21/WG5  (FT AM)  and  SC18/WG4  (DFR)  in  Stockholm  in 
May  1989  concluded  that  due  to  the  different  user  requirements  being  met  by  the  two  standards,  a 
general-store  model  could  not  be  progressed.  [Ref.  OSN  1989a] 

7.1.7  Referenced  Data  Transfer  (RDT) 

RDT  standards  have  been  developed  by  ECMA  TC32-TG5  and  ISO/IEC  JTC1 
SC18/WG4.  The  RDT  protocol  duplicates  functionality  provided  by  FT AM,  specifically  the 
simple,  efficient  transfer  of  unstructured  data  (this  is  provided  by  FT AM-3  and  die  FT AM  Transfer 
Service  Class).  However,  a  minimal  implementation  of  FT AM  would  not  provide  all  the  apparent 
RDT  requirements,  such  as  security,  single/multiple  use  of  reference,  finite  life  of  reference,  and 
use  over  a  single  association  along  with  the  RTSE.  ISO  10740,  Information  Technology  -  Text 
and  Office  Systems  -  Referenced  Data  Transfer,  which  was  approved  in  1993,  has  the  following 
parts: 

•  ISO  10740-1  (Part  1):  Abstract  Service  Definition 

•  ISO  10740-2  (Part  2):  Protocol  Specification. 
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7.1.8  DoD  Document  Exchange  Standards 

The  US  DoD  has  developed  the  following  standards  for  document  format  and  exchange: 

•  DoD-STD-7935,  Automated  Data  Systems  (ADS)  Documentation,  February  1983 

•  MIL-M-38784B,  Manuals,  Technical:  General  Style  and  Format  Requirements, 
February  1991 

•  MIL-STD-1840B,  Automated  Interchange  of  Technical  Information,  November  1992 

•  DoD- STD-2 167  A,  Defense  System  Software  Development,  February  1988. 

DoD-STD-7935  provides  guidelines  for  the  development  and  revision  of  the  documentation 

for  Automated  Data  Systems  (ADS)  of  applications  computer  programs,  and  it  prescribes  the 
standards  and  descriptions  for  each  of  the  technical  documents  to  be  produced  during  the  life  cycle 
of  an  ADS.  ADS  is  defined  as  "an  assembly  of  procedures,  processes,  methods,  routines,  or 
techniques  (including,  but  not  limited  to,  computer  programs)  united  by  some  form  of  regulated 
interaction  to  form  an  organized  whole,  specifically  designed  to  make  use  of  automatic  data 
processing  equipment"  The  objective  of  the  standard  is  to  provide  managers  of  ADS  projects  with 
documentation  of  uniform  format  and  content  for  review  to  assure  the  meeting  of  significant 
development  milestones.  It  also  provides  ADS  technicians  with  a  standard  record  of  technical 
information  as  a  basis  for  coordination  of  later  ADS  development  or  use  modification.  There  are 
11  technical  documents  described  in  the  standard:  Functional  Description,  System/Subsystem 
Specification,  Data  Base  Specification,  Computer  Operational  Manual,  Test  Plan,  Implementation 
Procedures,  Data  Requirement,  'raiment,  Program  Specification,  Users  Manual,  Program 
Maintenance  Manual,  and  Test  dysis  Report  A  proposed  outline  and  text  format  for  each 
document  type  is  provided  in  Section  3.0  of  die  standard. 

MIL-M-38784B  is  a  military  specification  approved  by  the  DoD  for  use  in  developing 
technical  manuals.  Technical  manuals  are  publications  that  contain  instructions  for  the  installation, 
operation,  maintenance,  training,  and  support  of  weapon  systems,  weapon  system  components, 
and  support  equipment.  Manuals  prepared  in  accordance  with  this  specification  are  intended  for 
use  in  the  operation  and  maintenance  of  equipment  or  for  accomplishment  of  assigned  missions.  It 
covers  the  general  style  and  format  requirements  for  the  preparation  of  manuscripts  and 
reproducible  copy  for  standard  technical  manuals  and  changes  to  those  manuals.  The  only  decision 
left  to  die  author  Of  a  technical  manual  is  the  actual  technical  content  of  the  manual;  even  the  style  of 
writing  is  specified  (US  Government  Printing  Office  Style  Manual). 

The  major  section  of  MIL-M-38784B,  Section  3.2,  is  dedicated  to  format  issues.  The 
specification  covers  everything  from  the  size  of  the  paper  to  capitalization  to  suggested  type  styles 
and  sizes.  The  specification  identifies  the  structure  of  a  technical  manual.  It  specifies  what  will  be 
included  in  the  manual  outline  and  publication  divisions  (volumes,  parts,  chapters,  sections,  and 
paragraphs).  Paragraphs  are  divided  into  primary  and  subordinate  paragraphs.  The  last  sections 
of  the  specification  discuss  how  to  make  changes  to  a  technical  manual,  quality  assurance 
provisions  (e.g.,  readability),  and  preparation  for  delivery  (packaging). 

The  purpose  of  MIL-STD-  1840B  is  to  standardize  the  digital  interface  between 
organizations  or  systems  exchanging  digital  forms  of  technical  information  necessary  for  the 
logistic  support  of  weapon  systems  throughout  their  life  cycle.  This  standard  addresses  technical 
information  and  product  definition  data.  It  standardizes  the  format  and  information  structures  of 
digital  data  files  used  for  the  transfer  and  archival  storage  of  digital  technical  information.  The 
format,  information  structures,  and  transfer  procedures  are  applicable  in  all  cases  where  the 
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information  can  be  prepared  and  received  in  the  form  of  American  Standard  Code  for  Information 
Exchange  (ASCII)  text  files,  product  definition  data  files,  raster  image  files,  or  graphics  files. 

Technical  publications  addressed  by  MIL-STD- 1 840B  consist  of  text  and  associated 
illustrations.  The  files  of  a  technical  publication  consist  of  a  declaration  file,  text  files  (in  ASCII) 
tagged  to  the  contract  (may  use  MIL-M-28001B),  illustration  files  (in  Initial  Graphics  Exchange 
Specification  (IGES),  Computer  Graphics  Metafile  (CGM),  or  raster  format),  files  in  Page 
Description  Language  (PDL)  form,  and  other  files  (output  specification  file,  special  word  file, 
etc.).  The  standard  dictates  very  detailed  requirements  for  the  structure,  content,  and  order  of 
information.  For  example,  the  declaration  file  must  precede  the  data  files  and  provide  information 
about  die  identifications,  source,  destination,  and  classification  of  the  document  The  standard  also 
specifies  the  file  header  records  for  textual  data,  CGM  data,  document  type  definition,  program 
descriptive  language  (PDL)  data,  IGES  data,  gray  scale,  raster  data,  special  word,  and  output 
specification  data. 

DoD-STD-2167A  provides  the  means  for  establishing,  evaluating,  and  maintaining  quality 
in  software  developed  for  weapon  systems  and  its  associated  documentation.  The  contract  agency 
is  responsible  for  tailoring  the  software  management  process  to  meet  the  needs  of  a  particular 
project  The  data  item  descriptors  (DEDs)  associated  with  this  standard  describe  a  set  of  documents 
for  recording  information  required  by  the  management  process.  The  standard  encourages  the 
production  of  deliverable  data  using  automated  techniques. 

7,1.9  Data  Descriptive  File34 

ISO  821 1,  Specification  for  a  Data  Descriptive  File  for  Information  Interchange,  December 
1985,  has  potential  value  for  data  interchange  as  a  medium-independent  and  system-independent 
file  and  record  format.  It  could  be  used,  for  example,  for  interchange  of  graphical  data  structures 
and  files  between  computer  systems.  It  could  also  be  used  for  exchange  of  geographical  data. 
There  was  also  interest  in  this  standard  for  use  in  the  SC21  data  management  export/import  project 

The  following  standards  documents  use  ISO  8211: 

•  Digital  Geographic  Information  Exchange  Standard  (DIGEST)  (see  Section  7.3.1) 

•  Spatial  Data  Transfer  Specification  (SDTS)  (US  FIPS  173;  see  Section  7.3.8) 

•  British  Standard  Specification  for  Geographic  Information — National  Transfer  Format 
(NTF)  (see  Section  7.3.9) 

•  International  Hydrographic  Organization  Transfer  Format  DX-90,  SP-57 

•  Spatial  Archive  and  Interchange  Format  (SAIF)  (for  use  in  Canada) 

•  Standards  being  developed  by  the  Japanese  Information  Center  for  Science  and 
Technology  (JICST) 

•  Multinational  Side-Scan  Sonar  Distribution  (SSS). 

ISO  8211  and  the  standards  cited  above  that  are  based  on  ISO  8211  are  in  wide  use.  In  the  United 
Kingdom,  these  standards  are  used  by  the  Ordnance  Survey,  Military  Survey,  Hydrographic 
Office,  and  Laser-Scan,  Inc.  US  use  includes  organizations  such  as  the  Bureau  of  the  Census, 
Geological  Survey,  Defense  Mapping  Agency  (for  the  ARC  Digital  Raster  Graphics,  World  Vector 
Shoreline,  and  Digital  Chart  of  the  World),  National  Oceanographic  and  Atmospheric 
Administration  (NOAA)  National  Charting  Division,  and  Department  of  the  Navy.  It  is  used  in 
software  developed  for  use  in  most  NATO  nations. 


34  Bated  on  [DRA 1994]. 
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A  second  edition,  DIS  821 1.2,  October  1993,  has  been  developed  with  changes  to  provide 
support  for  compound  arrays  (concatenated  regular  data  structures);  extended  (multi-byte)  character 
sets;  better-specified  support  for  simple  binary  data;  fixed  point,  floating  point,  and  complex  binary 
data;  and  recursive  tree  structures  in  Level  3.  The  primary  negative  comment  on  DIS  821 1.2  was 
that  it  is  poorly  structured  and  uses  terminology  loosely  and  inconsistently,  so  that  the  technical 
content  might  be  misunderstood. 

7.2  Graphical  Data  Exchange 

Existing  military  information  systems  support  the  generation  and  display  of  graphics,  a 
capability  that  will  continue  to  be  required  in  the  future.  Graphics  are  generally  not  distributed. 
Instead  the  underlying  data  are  distributed  and  the  graphics  are  regenerated  at  each  location  where 
they  are  needed.  In  the  future  the  graphics  may  need  to  be  exchanged.  What  is  needed  is  a 
common  standard  intermediate  form  in  which  to  transmit  graphics,  such  as  exists  in  other  areas  of 
publishing.  [Ref.  Carlson  1991]  Moreover,  there  is  growing  interest  in  using  graphics  for 
simulation  purposes.  [Ref.  IDA  1991,  p.  152] 

Section  7.2.1  describes  two  standards  for  exchange  of  graphical  information  products: 
Initial  Graphics  Exchange  Specification  (IGES)  and  the  Standard  for  the  Exchange  of  Product 
Model  Data  (STEP,  formerly  PDES).  Standards  for  graphics  interchange  services  (e.g..  Computer 
Graphics  Metafile),  Computer  Graphics  Interface  (CGI),  the  Image  Processing  and  Interchange 
(DPI)  standard,  and  National  Imagery  Transmission  Format  Standard  (NITFS)  are  addressed  in 
Section  7.2.2.  Two  graphics  standards  are  treated  separately  in  Chapter  8:  the  Graphics  Kernel 
System  (GKS)  and  the  Programmer's  Hierarchical  Interactive  Graphics  System  (PHIGS). 

7.2.1  Graphical  Information  Product  Exchange 

7.2.1. 1  IGES 

The  IGES,  Version  4.0,  is  an  ANSI  standard  ( Digital  Representation  for  Communication 
of  Product  Definition  Data,  Y14.26M-1989)  developed  by  the  American  Society  for  Mechanical 
Engineers  (ASME).  It  is  based  on  the  work  of  the  IGES/PDES  Organization,  which  is  chaired  by 
NIST.  This  group  establishes  information  structures  to  be  used  for  the  (1)  digital  representation 
and  communication  of  product  definition  data  and  (2)  representation  and  transfer  of  vector 
graphics  data  used  by  various  Computer  Aided  Design  and  Computer  Aided  Manufacturing 
(CAD/CAM)  systems.  IGES  Version  5.1  has  been  released  and  Version  6.0  will  be  processed  as 
an  ANSI  standard.  [Ref.  APP  1992]  FIPS  177,  Initial  Graphics  Exchange  Specification  (IGES), 
based  on  ASME/ ANSI  Y14.26M-1989,  was  issued  in  November  1992. 

MIL-D-28000A,  Digital  Representation  for  Communication  of  Product  Data:  IGES 
Application  Subsets,  February  1992,  identifies  the  requirements  to  be  met  when  product  definition 
data  are  delivered  in  the  digital  format  of  IGES  as  specified  by  ANSI  standard  Y14.26M.  MIL-D- 
28000A  is  designed  to  be  incorporated  into  a  contract  to  define  the  technical  requirements  to  be  met 
when  purchasing  product  definition  data  or  product  data  in  digital  form.  The  concept  of  product 
definition  data  is  defined  in  MIL-D-28000A  as: 

.  ..the  totality  of  data  elements  required  to  completely  define  a  product  Product 
definition  data  includes  geometry,  topology,  relationship,  tolerances,  attributes  and 
features  necessary  to  completely  define  a  component  part  or  an  assembly  of  parts 
for  die  purpose  of  design,  analysis,  manufacture,  test,  and  inspection. 
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The  specification  defines  product  data  as  "all  data  Elements  necessary  to  define  the  geometry,  the 
function,  and  the  behavior  of  a  piece  part  or  an  assembly  of  parts  over  its  entire  life  span.” 

MIL-D-28000A  defines  the  technical  requirements  for  the  exchange  of  digital  product  data 
in  specific  application  subsets.  These  subsets  are  technical  illustrations,  engineering  drawings,  and 
electrical/electronic  applications.  The  technical  illustration  subset  addresses  entities  that  support  the 
exchange  of  figures  and  illustrations  normally  found  in  a  technical  publication.  The  emphasis  is  on 
visual  clarity  for  human  interpretation.  The  engineering  drawings  subset  is  used  to  encode  product 
data  being  acquired  in  accordance  with  DoD-D-1000  ( Engineering  Drawings  and  Associate  Lists ) 
for  delivery  in  digital  form.  Exchange  emphasis  is  on  completeness,  visual  equivalency  for  human 
interpretation,  and  functionality  of  the  received  drawing  model.  The  electrical/electronic 
applications  subset  addresses  the  representation  and  exchange  of  electrical  and  electronic  products 
including  printed  wiring  boards,  printed  wiring  assemblies,  hybrid  micro-assemblies,  cables,  and 
wiring  harnesses.  Emphasis  is  on  component  and  circuit  element  descriptions,  their  placement, 
their  connectivity,  and  the  routing  of  electrical  paths. 

NIST  is  evaluating  test  tools  for  IGES  Testing  and  expects  a  test  service  to  be  available  in 
1993  [Ref.  Cugini  1992].  One  commercial  conformance  testing  service  offered  for  IGES  is 
located  at  the  CAD-CAM  Data  Exchange  Technical  Centre  (CADDETC)  in  the  Uv  [Ref. 
CALS  1992] 

7.2. 1.2  STEP 

An  alternative  to  IGES  for  product  data  interchange  is  STEP,  which  is  being  developed  by 
ISO  (CD  10303).  STEP  was  previously  known  as  PDES,  but  the  name  was  changed  to 
differentiate  it  from  the  IGES/PDES  Organization  (IPO),  a  voluntary  organization  of  more  than  530 
American  industrial,  governmental,  and  academic  entities,  which  began  work  on  STEP  in  mid- 
1984.  In  April  1988,  several  major  technology  companies  were  incorporated  as  PDES,  Inc.,  an 
international  consortium  dedicated  to  accelerating  the  development  and  adoption  of  the  STEP 
standard.  [Ref.  PDES  n.d.] 

STEP  is  in  the  draft  stage  and  may  undergo  revision  at  any  time.  The  first  version  of  STEP 
was  scheduled  to  reach  DIS  status  in  December  1992.  [Ref.  Bloom  1992]  ISO  standardization  is 
expected  in  1994.  [Ref.  APP  1992]  EXPRESS ,  Part  11  of  the  STEP  standard  (CD  10303),  is  an 
object-flavored  information  modelling  language  that  has  been  developed  to  enable  a  formal 
specification  of  STEP.  It  is  rapidly  becoming  the  language  of  choice  for  the  formal  specification  of 
other  data  exchange  standards,  especially  in  the  electronics  area.  Currently,  the  language  has  two 
forms:  (1)  EXPRESS  itself,  a  computer  processable  lexical  language,  and  (2)  EXPRESS-G,  a 
graphical  subset  of  the  lexical  form  developed  to  enable  a  visually-oriented  display  of  information 
models.  A  third  form,  EXPRESS-I  is  in  development  as  an  instantiation  language  for  data  models 
based  on  EXPRESS-defined  information  models.  [Ref.  Rensselaer  1992] 

Since  STEP  is  not  being  built  on  an  established  technology  with  existing  implementations, 
"validating”  the  standard  is  necessary  before  its  adoption.  The  National  PDES  Testbed  (NPT), 
located  at  NIST,  was  established  in  1990  to  do  this.  It  is  developing  a  system  for  testing  and 
evaluating  the  application  protocols,  specifying  and  validating  at  least  one  application  protocol 
defined  in  STEP,  and  developing  a  conformance  testing  system  and  an  institutional  framework  for 
validation  to  be  used  to  test  commercial  STEP  implementations  and  certify  that  they  comply  with 
the  standard  application  protocol.  [Ref.  CALS  1992] 
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7.2.2  Standards  for  Graphics  Services 

This  section  reviews  the  Computer  Graphics  Reference  Model,  Computer  Graphics 
Metafile  (CGM),  and  Computer  Graphics  Interface  (CGI).  Chapter  8  reviews  other  graphics 
service  standards,  including  the  Graphical  Kernel  System  (GKS)  (see  Section  8.2)  and  the 
Programmer's  Hierarchical  Interactive  Graphics  System  (PH3GS)  (see  Section  8.3). 

7.2.2. 1  Computer  Graphics  Reference  Model 

The  Reference  Model  for  Computer  Graphics  (ISO  1 1072)  defines  a  basic  architecture  and 
consistent  terminology  for  computer  graphics.  It  addresses  environment;  primitives;  geometry, 
attributes,  and  aspects  of  primitives;  pictures;  collections;  metafiles;  and  archives.  There  are  four 
environments:  application  (to  which  an  application  interfaces),  virtual,  logical,  and  physical  (to 
which  the  user  interfaces).  [Ref.  RM  1989] 

7. 2. 2. 2  Computer  Graphics  Metafile  (CGM) 

CGM  standards  provide  a  file  format  suitable  for  the  storage  and  retrieval  of  picture 
information.  The  file  format  consists  of  a  set  of  elements  that  can  be  used  to  describe  pictures  in  a 
way  that  is  compatible  between  systems  of  different  architectures  and  devices  of  differing 
capabilities  and  design.  ISO  8632  is  a  standard  for  producing  a  CGM  in  order  to: 

•  Allow  picture  information  to  be  stored  in  an  organized  way  on  a  graphical  software 
system 

•  Facilitate  transfer  of  picture  information  between  different  graphical  software  systems 

•  Enable  picture  information  to  be  transferred  between  graphical  devices 

•  Enable  picture  information  to  be  transferred  between  different  computer  graphics 
installations. 

The  CGM  standards  are: 

•  ISO  8632-1,  Functional  Specification 

•  ISO  8632-2,  Character  Encoding 

•  ISO  8632-3,  Binary  Encoding 

•  ISO  8632-4,  Clear  Text  Encoding. 

Vendors  commonly  use  CGM  as  an  exchange  format  for  the  storage,  interchange,  or  output 
of  a  wide  range  of  graphical  pictures  and  numerous  CGM  implementations  exist  for  use  in  federal 
procurements.  Virtually  all  major  microcomputer  software  products  can  generate  and/or  interpret 
CGM  files.  Moreover,  most  CGM  implementations  conform  to  the  CALS  Application  Profile. 
CGM  is  considered  to  be  mature  and  stable.  [Ref.  APP 1991,  p.  37-38] 

MIL-D-28003A,  Digital  Representation  for  Communication  of  Illustration  Data:  CGM 
Application  Profile ,  November  1991,  defines  use  of  the  CGM  for  two-dimensional  vector  (line 
segment)  picture  descriptions  or  illustrations  in  technical  manuals.  Whereas  IGES  has  its  principal 
use  within  computer-aided  design,  CGM  is  becoming  widely  available  for  authoring  and  graphic 
art  workstations.  [Ref.  CALS/CE  1992] 

A  CGM  test  service  was  launched  by  NIST  in  May  1991.  The  service,  analyzes  a  CGM 
file  to  see  if  it  meets  requirements  that  allow  the  transfer  of  pictures  among  different  graphical 
software  systems,  graphical  devices,  and  computer  graphics  installation.  The  File  Conformance 
Test  Service  tests  for  conformance  to  FIPS  128,  Computer  Graphics  Metafile,  and  MIL-D- 
28003A,  CALS  Application  Profile,  December  1988.  Additionally  a  test  service  for  CGM 
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Generator  Conformance  is  being  beta  tested.  NIST  is  designing  the  test  for  an  Interpreter  Testing 
Service.  [Ref.  Cugini  1992] 

7. 2. 2. 3  Computer  Graphics  Interface  (CGI) 

ISO  and  ANSI  have  drafted  the  CGI  standard,  formerly  the  Computer  Graphics  Virtual 
Device  Interface  (CG-VDI),  to  provide  a  standard  specification  of  the  control  and  data  interchange 
between  device-independent  graphics  software  and  one  or  more  device  drivers  by  defining  an 
interface  to  a  virtual  graphics  device.  Device  dependencies  are  allowed  in  limited  circumstances, 
such  as  when  dealing  with  raster  entities  (this  is  the  first  graphics  standard  to  contain  explicit 
operations  dealing  with  raster  graphics  displays).  It  is  designed  as  a  system-level  interface  to 
provide  efficient  device-independent  access  to  graphics  devices  and  processes,  but  it  provides  little 
error  checking  or  error  handling.  Character,  binary,  and  clear-text  codings  are  provided.  This 
functional  specification  is  also  supported  by  language  bindings  that  specify  the  exact  name  for  each 
operation,  its  parameter  sequence,  and  data  types  for  the  parameters. 

The  ISO/IEC  approach  to  defining  a  CGI  is  provided  in  ISO/EEC  9637,  Computer 
Graphics  -  Interfacing  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Data  Stream 
Encoding.  The  standard  comprises  three  parts: 

•  DIS  9637-1  (Part  1):  Character  Encoding 

•  ISO/IEC  9637-2  (Part  2):  Binary  Encoding 

•  DIS  9637-3  (Part  3):  Clear  Text  Encoding. 

The  governing  CGI  standard  is  ISO/IEC  9636,  Computer  Graphics  -  Interfacing 
Techniques  for  Dialogues  with  Graphical  Devices  -  Functional  Specification  (CGI),  which  has  the 
following  parts: 

•  ISO/IEC  9636-1  (Part  1):  Overview,  Profiles,  and  Conformance 

•  ISO/IEC  9636-2  (Part  2):  Control,  Negotiation,  and  Errors 

•  ISO/IEC  9636-3  (Part  3):  Output  and  Attributes 

•  ISO/IEC  9636-4  (Pa*  4):  Segmentation 

•  ISO/IEC  9636-5  (Part  5):  Input  and  Echoing 

•  ISO/IEC  9636-6  (Part  6):  Raster 

•  WD  9636-8  (Part  8):  FORTRAN  Language  Binding  of  CGI 

•  WD  9636-11  (Part  1 1):  C  Language  Binding  of  CGI. 

DIS  9638,  CGI  Language  Bindings,  has  the  following  parts: 

•  DIS  9638-1  (Part  1):  FORTRAN 

•  DIS  9638-2  (Part  2):  Pascal 

•  DIS  9638-3  (Part  3):  Ada 

•  DIS  9638-4  (Part  4):  C. 

NIST  is  monitoring  conformance  tests  being  developed  for  CGI  by  the  European 
Community.  [Ref.  Cugini  1992] 

7.2. 2. 4  Image  Processing  and  Interchange  (IPI) 

SC24/WG1  is  developing  an  Image  Processing  and  Interchange  (IPI)  standard 
(DIS  12087).  Part  1  establishes  the  conceptual  and  architectural  definitions  of  the  Common 
Architecture  for  Imaging  (CAI)  of  the  standard.  Part  2  establishes  the  specification  of  the 
application  program  interface  (API)  part  of  the  standard,  called  the  Programmer's  Imaging  Kernel 
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System  (PIKS).  Part  3  is  the  Image  Interchange  Facility  (IIF).  [Ref.  SC24  N  744  1992] 
DIS  12087  is  intended  for  use  in  a  wide  variety  of  environments  where  image  data  are  handled. 
Table  10  indicates  the  specific  areas  included  and  excluded  in  the  terms  of  reference  of  the 
standard. 

DIS  12087  is  intended  to  conform  with  other  international  standards  developed  to  handle 
image  data.  Such  standards  include  the  Joint  Bi-Level  Imaging  Group  (JBIG)  [ISO/IEC  1 1544] 
and  Joint  Photographic  Experts  Group  JPEG)  [ISO/IEC  10918-1]  compression  standards  (see 
Section  7.4),  ASN.l  [ISO  8824:1990]  (see  Section  9.10.1),  and  ODA  [ISO  8613]  (see  Section 
7.1.1).  Aspects  of  the  standard  that  are  concerned  with  the  acquisition  and  display  of  image  data 
conform  with  the  Computer  Graphics  Reference  Model  [ISO/IEC  1 1072]  and  its  annexes.  Part  3 
of  this  standard  uses  ASN.l  [ISO  8824:1990]  in  the  definition  of  the  IIF. 


Tabla  10.  Scop*  of  DIS  12087  on  Imago  Processing  and 

Intarchango 


Included  in  IPt 

Excluded  from  IPI 

primitive  image  manipulations 
image  enhancement 
image  restoration 
image  analysis 
image  classification  (basic) 
standard  color  models 
image  transport 

image  compression  and  decompression 

computer  graphics 
device  control 
image  understanding 
multimedia 
communications 
window  systems 
sensor  image  acquisition 
image  presentation 

Source:  DIS  12087. 1993. 


In  a  recent  liaison  to  SC21,  SC24  noted  that  further  improvements  in  the  Packed  Encoding 
Rules  of  ASN.l  are  desirable  for  encoding  the  IPI-IIF  (see  Section  9.10.2).  These  improvements 
should  address  the  encoding  of  multi-dimensional  arrays.  [Ref.  SC21 N  7643  1993] 

7 .2.2. 5  National  Imagery  Transmission  Format  (NITF) 

The  National  Imagery  Transmission  Format  Standard  (NITFS)  is  the  standard  for 
formatting  digital  imagery  and  imagery-related  products  and  exchanging  them  between  members  of 
the  Intelligence  Community,  the  US  DoD,  and  other  departments  and  agencies  of  the  US 
Government  It  ensures  interoperability  of  systems  used  for  formatting,  transmitting,  receiving, 
and  processing  imagery  and  imagery-related  information.  The  NITFS  is  in  essence  the  suite  of 
individual  standards  that  includes  the  following:  transmission  format  four  different  types  of  image 
bandwidth-compression  algorithms,  communications  protocol,  forward  error  correction.  Computer 
Graphics  Metafile,  and  the  NITFS  Handbook.  Over  30  different  system  configurations  have  been 
certified  compliant  with  National  Imagery  Transmission  Format  (NITF)  Version  1.1.  NITFS  is  in 
Version  2.0.  The  key  improvement  in  Version  2.0  is  the  inclusion  of  a  communications  support 
capability,  to  enable  NITF  to  be  transmitted  over  tactical  circuits.  Additionally,  improved  image 
compression,  forward  error  correction,  and  enhanced  graphics  algorithms  were  added.  The 
relevant  standards  and  specifications  are: 

•  MIL-HDBK-1300,  National  Imagery  Transmission  Format  Standard  (NITFS), 
June  1993 

•  MIL-STD-188-196,  Bi-Level  Image  Compression  for  the  National  Imagery 
Transmission  Format  Standard,  June  1993 
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•  MIL-STD-188-197,  Adaptive  Recursive  Interpolated  Differential  Pulse  Code 
Modulation  ( ARIDPCM )  Compression  Algorithm  for  the  National  Imagery 
Transmission  Format  Standard,  June  1993 

•  MIL-STD-198,  Joint  Photographic  Experts  Group  (JPEG)  Image  Compression  for 
National  Imagery  Transmission  Format  Standard,  June  1993 

•  MIL-STD-2045-44500,  Tactical  Communications  Protocol  2  (TAC02)  for  National 
Imagery  Transmission  Format  Standard,  June  1993 

•  MIL- STD-2301 ,  Computer  Graphics  Metafile  ( CGM)  Implementation  Standard  for  the 
National  Imagery  Transmission  Format  Standard,  June  1993 

•  MIL-STD-2500,  National  Imagery  Transmission  Format  (Version  2.0)  for  the 
National  Imagery  Transmission  Format  Standard,  June  1993. 

7.3  Geographical  Data  Exchange 

This  section  covers  standards  and  standardization  activities  in  geographic  information 
exchange.  Digital  cartographic  and  geographic  information  systems  have  existed  for  several  years; 
however,  their  widespread  use  has  been  impeded  by  difficulties  in  data  collection  and  the  need  for 
information  sharing  standards.  Perhaps  the  most  fundamental  distinction  between  the  digital 
representation  of  cartographic  data  and  the  conventional  printed  graphic  is  the  need  to  explicitly  and 
unambiguously  code  the  attributes  and  spatial  relationships  among  the  various  data  elements. 
Because  of  the  massive  amounts  of  information  that  must  be  stored,  data  compression  is  a  related 
topic  of  interest  (see  Section  7.4). 

Specific  information  system  requirements  for  the  processing  and  interchange  of  maps  and 
geographical  information  include  the  abilities  to  [Ref.  IDA  1991,  p.  157]: 

•  Display  and  transfer  a  working  color  map  between  two  or  more  headquarters 

•  Change  map  features,  post  symbols,  and  have  zoom  capability 

•  Receive,  store,  process,  display,  and  integrate  all  environmental  data. 

Requirements  for  use  of  geographic  information  systems  (GISs)  for  command  and  control 

are  being  treated  in  several  international  forums.  In  October  1989,  a  symposium  on  GISs  was  held 
at  the  SHAPE  Technical  Centre  in  The  Hague.  This  symposium  addressed  requirements, 
standards,  and  implementation  aspects  of  GISs  for  military  application.  Examples  of  digital  data 
that  may  be  required  for  military  use  of  GISs  are  [Ref.  Baybrook  1990]: 

•  Electronic  maps  and  tactical  terrain  data. 

•  Intelligent  spatial  data,  to  include  maintaining  topological  relationships  interactively, 
presenting  a  feature-based  view  of  the  data  in  which  attributes  can  be  easily  requested 
interactively,  supporting  high-speed  interactive  queries  (for  which  parallel  processors 
and  rule-based  software  may  be  required),  and  maintaining  prioritized  feature 
symbolization  during  creating  and  editing  of  feature  data. 

•  Topologically  structured  vector  data  to  support  exchange  and  display  of  electronic 
maps,  tactical  terrain  data,  and  user- generated  queries.  Features  and  attributes  of  the 
features  are  associated  with  points,  lines,  and  areas.  Each  geographic  element  is 
captured  and  stored  only  once,  together  with  attributes  and  relationships  to  other 
elements. 

•  Intelligence  collection,  data  fusion,  and  intelligence  preparation  of  the  battlefield. 

•  Battle  management,  mission  planning,  tactical  maneuver,  and  interdiction. 

•  Fire  support  and  close  air  support 

•  Antisubmarine  warfare. 
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Digital  cartographic  and  geographic  standards  generally  address  (1)  encoding  or 

(2)  exchange.  Typically  they  reference  one  another.  Currently,  all  exchange  standards  are 
designed  for  removable  media  as  opposed  to  establishing  communication  protocols  for  exchanging 
cartographic  and  geographic  information. 

There  are  four  basic  types  of  digital  cartographic  and  geographic  data: 

(1)  Digital  elevation  data 

(2)  Digital  planimetric  data 

(3)  Digital  land  use  and  land  cover  data,  and 

(4)  Digital  geographic  names  data. 

Several  United  States  Geological  Survey  (USGS)  circulars  cover  these  types  of  data: 

•  FIPS  PUB  70- 1 ,  Specifications  for  Representation  of  Geographic  Point  Location  for 
Information  Interchange,  1986  [USGS  Circular  878-B] 

•  FIPS  PUB  103,  Codes  for  Identification  of  Hydrologic  Units  in  the  United  States  and 
the  Caribbean  Areas,  1983  [USGS  Circular  878-A] 

•  USGS  Circular  895-B,  Digital  Elevation  Models 

•  USGS  Circular  895-C,  Digital  Line  Graphs  from  1:24,000 Scale  Maps 

•  USGS  Circular  895-D,  Digital  Line  Graphs  from  1:2,000,000  Scale  Maps 

•  USGS  Circular  895-E,  Land  Use  and  Land  Cover  Digital  Data 

•  USGS  Circular  895-F,  Geographic  Names  Information  System. 

FIPS  PUB  70-1  specifies  a  uniform  format  for  representing  geographic  point  location  data 
in  digital  form  for  purposes  of  information  interchange  among  data  systems.  It  applies  only  to  the 
three  coordinate  systems  most  widely  used  in  the  United  States  to  define  die  position  of  a  point  that 
may  be  on,  above,  or  below  the  earth's  surface. 

FIPS  PUB  103  adopts  the  set  of  codes  used  to  identify  hydrologic  units  published  in 
Geological  Survey  Circular  878-A.  These  codes  identify  a  hydrologic  system  that  divides  the 
United  States  and  Caribbean  outlying  areas  into  21  major  regions.  These  regions  are  further 
subdivided  into  approximately  2,150  units  that  delineate  river  basins  having  drainage  areas  usually 
greater  than  700  square  miles.  The  codes  provide  a  standardized  base  for  use  by  water-resources 
organizations. 

In  response  to  a  special  study  chartered  by  die  US  Joint  Requirements  Oversight  Council 
(JROC),  the  Defense  Mapping  Agency  (DMA)  established  a  program  of  standardization  in 
August  1990,  the  goal  of  which  is  to  develop  a  comprehensive  suite  of  standards  for  exchanging, 
manipulating,  and  displaying  digital  Mapping,  Charting,  and  Geodesy  (MC&G)  data.  The 
Mapping,  Charting  and  Geodesy  Technology  (MCGT),  standardization  area  will  provide  for  the 
compatibility  and  interoperability  of  digital  MC&G  databases  supporting  a  wide  variety  of 
simulators,  command  and  control,  and  weapons  systems.  [Ref.  DMA  cl990] 

Several  US  military  specifications  cover  digital  geographic  information  exchange: 

•  MIL-D- 89000,  Digital  Terrain  Elevation  Data  ( DTED ),  26  February  1990 

•  MEL-D-890G5,  Digital  Feature  Analysis  Data 

•  MDL-A-89007,  Arc  Digitized  Raster  Graphics. 

The  first  of  these,  MIL-D- 89000,  defines  the  requirements  within  the  DMA's  DTED 
database,  which  supports  various  weapon  and  training  systems.  The  purpose  of  MEL-D-89000  is 
to  assure  uniform  treatment  among  all  mapping  and  charting  elements  engaged  in  coordinated 
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production  and  maintenance  of  this  type  of  data.  The  UK  MOD  has  related  standards.  Digital 
Terrain  Elevation  Data  and  Digital  Feature  Analysis  Data. 

The  NATO  STANAGs  relevant  to  this  area  include: 

•  STANAG  3809,  Digital  Terrain  Elevation  Data  Exchange  Format 

•  STANAG  3985,  Preferred  Magnetic  Tape  Standards  for  die  Exchange  of  Digital 
Geographic  Information 

•  STANAG  3986,  Digital  Data  File  Transmittal  Form  for  Geographic  Information. 

7.3.1  Digital  Geographic  Information  Exchange  Standard  (DIGEST) 

The  11 -nation33  Digital  Geographical  Information  Working  Group  (DGIWG)  is  working 
on  DIGEST.  DIGEST  may  be  submitted  to  ISO,  but  no  definite  plan  for  this  has  been  identified. 
The  present  concern  is  for  magnetic  tape  exchanges,  with  electronic  communications  exchanges 
possible  in  the  future. 

The  following  are  the  specifications  for  DIGEST: 

•  Fart  1,  General  Description,  Draft,  Edition  1.1,  August  1992 

•  Part  2,  Theoretical  Model,  Exchange  Structure,  and  Encapsulation  Specifications, 
Draft,  Edition  1.1,  August  1992 

•  Part  3,  Codes,  Parameters,  and  Tags,  Draft,  Edition  1.1,  August  1992 

•  Part  4,  Feature  and  Attribute  Coding  Catalog  (FACC),  Draft,  Edition  1.1, 
August  1992. 

DIGEST  is  intended  for  standardizing  exchanges  of  digital  geographic  data  and  making 
compatible  the  digital  data  products  of  the  participating  nations;  the  draft  of  the  standard  was 
produced  in  October  1989.  This  draft  was  developed  to  accommodate  the  exchange  of  multiple 
data  sets  of  different  data  structures  using  a  single  format  DIGEST  has  two  parts.  The  Generic 
Standard  is  supplemented  by  the  Minimum  Standards  Specifications,  which  are  single-data- 
structure  oriented  subsets  of  the  Generic  Standard.  The  generic  standard  contains  the  necessary 
file,  record,  field,  and  subfield  definition  and  implementation  details  to  exchange  all  data  structures 
supported  by  the  standard.  Each  minimum  standard  specification  is  geared  towards  one  particular 
data  structure  and  serves  as  the  basis  for  the  exchange  of  data  only  in  that  structure.  The  current 
standard  supports  the  following  [Ref.  Schneider  1990]: 

•  Vector  topologically  structured  data,  which  includes  association  of  features  with 
individual  nodes  (e.g.,  water  tower),  edges  (e.g.,  two-lane  highway  with  an  asphalt 
surface),  faces  (e.g.,  forest  of  deciduous  trees),  and  collections  of  features  associated 
to  nodes,  edges,  and  faces  (e.g..  Route  1  for  a  series  of  line  features  or  city  for  a 
collection  of  three  types  of  features). 

•  Color-coded  and  red-green-blue  (RGB)  coded  raster  data: 

An  RGB  raster  image  is  a  collection  of  red,  green,  and  blue  color  bands,  which 
when  combined  for  display  purposes  form  the  original  color  of  the  source 
graphic. 

A  color-coded  image  represents  each  unique  color  of  a  scanned  graphic  as  a  series 
of  pixels,  which  represent  the  information  on  the  original  source  graphic  that 
utilized  that  color. 

The  raster  structure  supports  use  of  subsets  and  merged  sets. 


35  The  seven  member  nations  are  France,  Gemuny,  Italy,  the  Netherlands,  Norway,  (be  United  Kingdom,  and  the 
Unted  Stales.  The  four  active  observers  ait  Belgium,  Canada,  Denmark,  and  Spain. 
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-  The  raster  structure  also  supports  user-defined  parameters  to  indicate  scan 
direction  and  row  and  pixel  sequencing,  which  are  required  for  exchanging  data 
derived  from  scanners  that  have  different  capture  methods. 

•  Feature  Attribute  Coding  Catalog  (FACC)  for  feature  identification: 

Features  are  associated  with  spatial  coordinates  or  sets  of  coordinates. 

Attributes  may  be  associated  with  features  and  may  serve  to  designate  width, 
length,  material  composition,  etc. 

The  initial  version  of  the  FACC  has  300  feature  codes  and  125  attribute  types 
with  associated  values.  The  FACC  includes  a  recommended  attribute  set  for  each 
feature  code. 

•  Transmittal  Header  File  to  describe  characteristics  of  the  entire  transmittal  (e.g., 
originator,  edition  of  the  exchange  specification  used,  number  of  data  sets  in  the 
transmittal,  and  security  and  release  information  for  the  transmittal). 

•  Header  information  files  to  describe  global  characteristics  of  each  data  set  being 
exchanged  [e.g.,  quality  (currency,  accuracy,  and  completeness),  source,  projection 
type,  coordinates  of  the  geographic  limits  of  the  data  set,  data  structure  type]. 
Qualities  can  be  associated  with  features  and  attributes  as  well  as  with  data  sets. 

•  ISO  media  standards  [using  ISO  9660  for  Compact  Disk-Read  Only  Memory  (CD- 
ROM)  and  ISO  1001  for  magnetic  tapes]. 

•  Security  labeling. 

•  Format  implementation  compliant  with  ISO  82 1 1 ,  Specification  for  a  Data  Descriptive 
File  for  Information  Interchange. 

Standards  for  two  other  data  structures  are  being  developed  for  future  versions  of  DIGEST: 
matrix  (to  support  exchange  of  elevation  data)  and  spaghetti  vector  (to  support  exchange  of  non- 
topological  vector  data). 

DGIWG's  position  is  that  DIGEST  data  should  be  exchanged  between  map-producing 
agencies,  such  as  the  Defense  Mapping  Agency  (DMA),  and  not  between  operational  units. 
Standards  governing  exchanges  between  field  systems  are  the  responsibility  of  the  system 
development  organization.  This  is  a  traditional  view  in  military  systems  development  organizations 
and  leads  to  substantial  interoperability  problems,  particularly  intra-national.  The  official  position 
notwithstanding,  the  DGIWG  is  encouraging  the  distribution  of  DIGEST  by  its  member  nations  to 
the  widest  possible  audience,  including  the  military  services  and  civilian  users. 

7.3.2  Geographic  Document  Architectures 

The  Directorate  of  Cartography  at  the  Canadian  National  Defence  Headquarters  has 
proposed  that  geographic  exchange  standards  be  built  on  a  document  architecture  similar  in  scope 
to  ODA  (see  Section  7.1.1).  This  architecture  would  address,  as  does  DIGEST,  a  range  of 
physical  media  such  as  magnetic  tape  and  CD-ROM.  It  would  also  address  exchange  of  partial 
data  sets  and  geographic  "document"  organizations.  Unlike  DIGEST,  the  architecture  would  not 
attempt  to  define  the  sets  of  feature  codes  and  attributes,  which  are  seen  as  dependent  on  political 
jurisdiction  and  intended  use.  For  example,  Canada  must  incorporate  more  geographic  ice  feature 
types  in  hydrographic  charts  than  many  other  countries.  The  proposed  architectural  concept  views 
the  architecture  as  a  vessel  that  carries  various  properly  labeled  containers  of  information. 
Specification  of  the  channels  for  transporting  the  vessel  are  left,  as  with  ODA,  to  OSI  or  other 
means  outside  the  scope  of  the  architecture.  Encapsulation  of  data  for  telecommunications  would 
use  ASN.l  (ISO  8824  and  8825)  and  for  physical  media  interchange  by  ISO  821 1.  Coding  of  the 
information  would  use  such  presentation  standards  as  ASCII  or  ISO  646  for  basic  text;  ISO  6937, 
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Supplementary  Characters ,  for  accents  to  the  text,  other  alphabets  (e.g.,  ISO  2375,  Non-Latin 
Alphabets),  and  ISO  9282,  Picture  Coding  (see  Section  7.4),  for  pictorial  information.  [Ref. 
McKellar  1990] 

7.3.3  SIMNET  Common  Geographic  Data  Model 

The  US  SIMNET  program  has  developed  a  geographic  data  model  to  integrate  such 
heterogeneous  data  types  as  digital  terrain  models,  traditional  maps,  and  satellite  and  aerial  imagery 
and  such  specialized  tools  as  digital  imagery  workstations,  GISs,  relational  DBMSs,  and  high- 
performance  graphics  workstations.  The  data  model  was  defined  using  ASN.  1,  which  provides  a 
concise,  unambiguous  means  of  specifying  abstract  data  types.  The  specification,  SIMNET 
Database  Interchange  Specification  [Ref.  Lang  1989],  recasts  the  specification  of  the  data  model 
into  a  relational  data  framework  in  order  to  take  advantage  of  relational  database  management  and 
query  capability. 

The  data  model  represents  features  in  spatial  and  non-spatial  components  that  can  be  further 
subdivided  for  separate  handling  and  also  reassembled  to  recover  the  complete  feature  description. 
Entities  in  SIMNET  (and  many  other  GIS  applications)  are  represented  as  objects.  For  example, 
networks  are  represented  as  collections  of  line  segments,  land  cover  is  represented  by  polygons, 
terrain  is  represented  by  a  triangulated  mesh,  and  modeled  objects  as  collections  of  points,  line 
segments,  and  triangles.  Classes  of  these  object  types  (such  as  a  class  of  tree  representations)  are 
generated  for  use  in  SIMNET  data  model.  Further,  the  data  model  permits  the  enlargement  of 
classes  and  addition  of  new  classes  of  objects.  For  example,  several  classes  of  trees  are  required 
for  simulation:  sets  of  individual  trees,  collections  of  irregular  groups  of  trees,  lines  of  trees, 
uniformly  wooded  areas,  and  generalized  surface  vegetation. 

The  spatial  model  represents  the  physical  aspects,  including  their  visual  appearance  and  die 
intervisibility  of  pairs  of  objects  (one  hides  a  part  of  the  other).  The  spatial  model  encompasses  die 
geometric  description,  the  location,  and  the  orientation  of  an  object  within  some  spatial  frame  of 
reference.  The  spatial  model  includes  aspects  that  are  expected  to  change  only  rarely  (e.g.,  the 
underlying  coordinate  system)  and  the  modifications  are  generally  only  to  enhance  the  fidelity  of 
the  representation  or  the  performance  (e.g.,  through  data  compression).  As  in  DIGEST,  the  spatial 
model  is  based  on  points,  line  segments,  and  triangles.  It  also  includes  tetrahedrons  for  three- 
dimensional  objects,  as  well  as  a  standard  technique  from  algebraic  topology  called  simplicial 
complexes  to  relate  the  various  geometric  elements.  In  this  technique,  triangles  are  2-simplexes, 
line  segments  are  1-simplexes,  and  the  three  line  segments  that  make  up  a  triangle  are  functions  of 
the  vertices  of  the  triangle. 

Hie  non-spatial  aspects  for  simulation  may  change  during  execution  of  a  simulation  and  are 
therefore  expected  to  be  dynamic.  These  aspects  are  treated  as  attributes  of  objects  as  a  whole  or  as 
a  component  Examples  are  color,  weight  power,  and  composition.  [Ref.  Lang  1990] 

7.3.4  IHO  Committee  for  file  Exchange  of  Digital  Data  (CEDD) 

The  International  Hydrographic  Organization  (IHO)  is  developing  standards  for  the 
exchange  of  digital  hydrographic  information.  The  work  is  being  done  by  the  CEDD.  No  world¬ 
wide  standards  have  yet  emerged  from  this  work.  One  effort  of  IHO,  called  the  North  Sea  Project 
is  establishing  an  electronic  chart  database,  testing  the  contents  of  this  database  for  electronic  chart 
display  systems,  and  evaluating  methods  of  electronic  navigational  chart  updating.  [Ref.  Stene 
19903 
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7.3.5  NATO  Geographic  Conference 

The  NATO  Geographic  Conference  meets  annually  (usually  in  June)  to  manage  and 
coordinate  digital  geographic  information  production  in  support  of  NATO  plans.  The  primary 
tasks  are  to  [Ref.  Matthews  1990]: 

•  Identify  common  national  and  NATO  requirements  for  digital  geographic  information 

•  Recommend  priorities  for  international  cooperative  production 

•  Recommend  outline  production  responsibilities  for  national  agreement 

•  Recommend  outline  rules  and  procedures  for  operational  geographic  support  and  its 
coordination. 

7.3.6  Digital  Chart  of  the  World  (DCW) 

The  DCW  is  a  research  and  development  project  of  the  US  DMA  to  develop,  refine,  and 
establish  a  suite  of  standards  that  enable  the  exchange  of  spatial  data  on  a  variety  of  exploitation 
systems.  The  DCW  employs  a  topologically  based  vector  structure  and  provides  digital 
representation  of  land  surface  information  on  30-40  CD-ROMs.  The  coverage  is  worldwide  and 
the  major  source  is  the  270  maps  of  the  1:1, 000, 000- scale  Operational  Navigation  Chart  series. 
The  DCW  is  the  forerunner  for  deployed  digital  databases  derived  from  DMA's  Digital  Production 
System  (DPS),  which  was  scheduled  to  produce  31  standard  products.  A  Map,  Chart,  and 
Geodesy  Feature  Data  Exchange  structure  is  being  defined  to  archive  and  exchange  DPS  products. 

7.3.7  Vector  Product  Standard  (VPS) 

This  standard  has  reached  a  prototype  stage.  A  military  standard  was  expected  to  have 
been  issued  in  early  1991  but  has  not  been  finalized.  Although  the  draft  standard  has  been 
distributed  to  the  civilian  community,  there  are  currently  no  plans  to  offer  VPS  as  a  civilian 
standard. 

7.3.8  Spatial  Data  Transfer  Specification  (SDTS) 

The  United  States  National  Committee  for  Digital  Cartographic  Standards,  a  multi-agency 
working  group  headed  by  the  USGS,  which  is  responsible  for  most  of  the  US  non-military 
geographic  information  exchange  standards,  has  issued  SDTS.  The  DMA  was  an  original 
participant  in  the  development  of  this  standard,  but  dropped  out  in  favor  of  its  own  activities. 
SDTS  has  been  approved  as  FIPS  173,  effective  February  1993.  Beginning  February  1994,  all 
Federal  agencies  will  be  required  to  use  FIPS  173.  [Ref.  Geo  1992]  The  USGS  is  prepared  to 
submit  the  SDTS  to  ANSI  for  promotion  as  an  ANSI  standard  and  then  to  ISO  for  promotion  as  an 
ISO  standard. 

The  SDTS  includes  definitions  of  terminology,  a  spatial  data  transfer  specification, 
methods  for  reporting  digital  cartographic  data  quality,  and  topographic  and  hydrographic  entity 
terms  and  definitions.  The  standard  will  allow  users  to  transfer  digital  spatial  data  sets  in  a  variety 
of  formats  between  dissimilar  computing  systems.  To  support  the  SDTS,  the  USGS  will 
coordinate  the  development  of  a  suite  of  software  tools  to  assist  users  in  interfacing  with  the 
standard.  These  tools  will  include  the  capability  to  encode  and  decode  the  standard  from  user- 
specified  data  models  and  formats  and  to  encode  and  decode  SDTS  data  sets  to  ISO  8211 
(Specification  for  a  Data  Descriptive  File  for  Information  Interchange).  [Ref.  McDermott  1991] 

Version  2  of  821 1  reached  DIS  status  in  January  1993.  It  has  been  produced  in  response 
to  the  need  for  a  mechanism  to  allow  data  structures  to  be  easily  moved  from  one  computer  system 
to  another,  independent  of  architecture.  The  standard  specifies  medium-independent  and  system- 
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independent  file  and  data  record  formats  for  the  interchange  of  information  between  computer 
systems. 

Other  standards  under  development  by  USGS  include: 

•  Aquifer  names  and  geologic  unit  codes 

•  Classification  of  wetlands  and  wildlife  services 

•  EPA  (Environmental  Protection  Agency)  parameter  codes 

•  Codes  for  taxonomic  identification  of  flora  and  fauna 

•  Land  use  and  land  cover  codes 

•  Public  land  survey  codes 

•  Cartographic  attribute/feature  codes. 

7.3.9  British  Standard  Specification  for  Geographic  Information 

Draft  British  Standard  BRDF,  British  Standard  Specification  for  Geographic  Information — 
National  Transfer  Format  (NTF),  is  a  standard  for  the  exchange  of  digital  map  data  between 
organisations.  The  NTF  is  designed  for  all  types  of  raster/grid  and  vector  map  data.  The 
specification  defines  media-independent  file  and  data  record  descriptions  for  information  exchange; 
description  of  data  elements,  vectors,  and  arrays  containing  character  strings  and  numeric  forms; 
relationships  between  data  elements;  and  volume  and  header  information  that  enables  data 
interchmge  to  occur  with  minimal  specific  external  description.  BSI 91/65602,  dated  July  1991,  is 
in  Release  1.2.  It  is  being  developed  by  the  British  Standards  Institute  Technical  Committee  36,  a 
committee  on  geographic  information  that  was  set  up  in  1991  within  die  Association  of  Geographic 
Information  which  is  acting  as  Secretariat. 

7.3.10  Emerging  Cartographic  Standards  for  Simulation 

A  derivative  of  the  SIMNET  Common  Geographic  Data  Model,  the  Project  2851  Standard 
Simulation  Data  Base  (SSDB)  offers  improvement  over  the  SIMNET  Data  Base  (see  Section 
7.3 3),  DTED,  Digital  Feature  Analysis  Data  (DFAD),  Interim  Terrain  Data  (TTD),  and  DIGEST 
(see  Section  7.3.1).  SSDB  incorporates  data  types  from  DTED,  DFAD,  and  ITD,  serving  as  a 
superset.  Terrain;  culture  information  such  as  slope,  vegetation,  surface  materials, 
surface  drainage,  transportation,  and  obstacles;  polygonal  and  Computer  Scene  Generation  (CSG) 
models;  and  raster  texture  images  are  included.  This  tri-service  project  has  two  possible  formats: 
SSDB  Interchange  Format  (SIF)  and  Generic  Transformed  Database  Format  (GTDF);  both  can  be 
derived  from  SSDB.  The  SIF  format  can  be  used  for  input  to  or  output  from  SSDB;  GTDF  is 
uaed  only  for  output  to  local  data  bases  for  image  generation.  SIF  is  currently  in  draft  form  as  a 
new  military  standard  and  is  the  format  of  choice  for  Distributed  Interactive  Simulation  (see  IEEE 
P1278-1993),  the  replacement  for  SIMNET. 

While  SIF  seems  to  require  more  data  than  other  standards,  it  has  more  capabilities. 
DRIEST  is  similar  to  DMA  DTED  and  DFAD.  It  offers  no  support  for  models  or  levels  of  detail 
(LOD).  The  SIMNET  Database  Interchange  Specification  does  not  support  terrain  grid  data,  geo- 
specific  texture,  and  its  format  is  not  easily  extended.  The  Spatial  Data  Transfer  Specification 
(SDTS)  (see  Section  7.3.8)  developed  by  the  USGS  is  still  in  a  development  stage  and  as  of 
March  1992,  the  USGS  did  not  plan  to  support  models.  The  DMA  Vector  Product  Format  (VPF) 
does  not  support  models,  texture  or  gridded  data.  The  Air  Force  is  developing  a  new  Common 
Mapping  Standard,  a  mix  of  old  and  emerging  formats  stored  as  WGS-84  data  which  are  not 
harmonized. 
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The  US  Geospatial  Standard*  Management  Committee  was  fanned  in  1993.  Consisting  of 
representatives  from  the  Services,  CINCs,  and  agencies  and  chaired  by  DMA,  it  provides  the 
management  structure  for  all  geospatial-related  standards  in  the  DoD. 

7.4  Data  aad  Image  Compression 

An  area  closely  related  to  map  and  geographic  information  is  data  compression  since  maps 
require  large  quantities  of  data.  For  example,  at  a  scale  of  1:1,000,000,  a  digitized  map  of  the 
world  requires  30  CD-ROMs.  The  Army  requires  maps  that  are  1:250,000  and  1:50,000.  The  use 
of  data  compression  is  not  limited  to  maps  however,  as  the  use  of  complex  computer  graphics 
proliferates  in  areas  such  as  desktop  publishing,  engineering,  and  industrial  design.  Individual 
manufacturers,  software  developers,  and  computer  services  have  adopted  their  own  internal 
storage  formats  and  data  compression  algorithms.  What  is  needed  is  a  unifying  standard.  [Ref. 
Carlson  1991] 

Some  of  the  available  image  storage  standards  and  commercial  software  implementations  of 
data  compression  schemes  include  [Ref.  Carlson  1991]: 

•  Utah  RLE  (Run  Length  Encoding)  -  University  of  Utah 

•  TIFF  (Tag  Image  Hie  Format)  -  Aldus  and  Microsoft 

•  PICT  Version  2  (Macintosh)  -  Apple 

•  IFF  (Interchange  File  Format)  -  Electronic  Arts 

•  GIF  (Graphics  Interchange  Formal)  -  CompuServe 

•  TGA  (Taiga  Image  Format)  -  Truevision,  Inc. 

•  Sun  Rasterfile  -  Sun 

•  GKS  (treated  separately  as  a  graphics  standard;  see  Section  8.2) 

•  CGI  (see  Section  7.2.2.3) 

•  ITU-T'S  Recommendation  T.4  (facsimile  transmission) 

•  ISO  1 1558,  Information  Technology,  Data  Compression  for  Information  Interchange, 
Adaptive  Coding  with  Embedded  Dictionary,  DCLZ  Algorithm,  1992. 

7.4.1  Joint  Photographic  Experts  Group  (JPEG) 

Joint  Photographic  Experts  Group  (JPEG)  is  a  joint  project  of  IEC/ISO  and  ITU-TS, 
which  has  issued  an  international  standard  referred  to  as  the  JPEG  standard  (ISO  10918).  The 
JPEG  standard  was  originally  concaved  as  a  companion  standard  to  Group  3  and  4  facsimile 
standards  covering  compression  and  decompression  of  still-frame,  continuous-tone,  photographic 
(gray  scale  or  color)  digitized  images.  The  standard  comprises  two  parts.  The  first  part  specifies 
four  modes  of  operation,  the  different  codes  specified  for  those  modes,  and  the  interchange  format 
It  also  contains  implementation  guidelines.  Several  vendors  have  already  introduced  JPEG- 
compatible  products.  [Ref.  Haber  1991]  A  second  standard  that  deals  with  still  pictures,  JBIG 
(Joint  Bi-Level  Imaging  Group),  is  also  under  development 

JPEG's  interest  in  data  compression  stems  from  a  desire  to  transmit  digital  representations 
of  photographs  by  facsimile.  To  achieve  the  desired  levels  of  quality  for  both  color  and  black  and 
white  requires  large  amounts  of  data  and  transmission  time.  The  MPEG  is  looking  at  data 
compression  techniques  for  motion  pictures,  reducing  the  data  needed  to  represent  each  frame,  and 
taking  advantage  of  the  redundancy  from  one  frame  to  the  next 


Chapter  7 


120 

UNCLASSIFIED 


Data  Interchange 


UNCLASSIFIED 


Digital  Compression  and  Coding  of  Continuous-Tone  Still  Images  (ISO/IEC  10918)  has 
the  following  parts: 

•  ISO/IEC  10918-1  (Part  1):  Requirements  and  Guidelines,  1993 

•  DIS  10918-2  (Part  2):  Compliance  Testing,  1993  (IS  status  expected  March  1994) 

•  WD  10918-3  (Part  3):  Extensions,  1993  (CD  status  expected  December  1994,  DIS  in 
April  1995,  and  IS  in  1996). 

7.4.2  Joint  Bi-Level  Imaging  Group  (JBIG) 

The  JBIG  standard.  Coded  Representation  of  Bi-level  and  Limited  Bits-per-pixel  Still 
Pictures  [ISO/IEC  11544],  will  be  used  to  compress  bi-level  images  such  as  black-and-white 
photos  or  pages  of  text  While  pixels  can  be  eliminated  without  the  loss  being  perceived  in  the 
continuous-tone  images  that  JPEG  deals  with,  JBIG  deals  with  simpler  images  where  there  can  be 
no  image  distortion.  The  American  National  Standard  for  JBIG  is  ANSI/AIIM  MS53-1993 
entitled  File  Format  for  Storage  and  Exchange  of  Images  -  Bi-Level  Image  File  Format:  Part  1. 
This  standard  defines  a  format  for  a  file  containing  one  page  with  one  image.  Page  sizes  and  image 
sizes  can  be  specified.  Both  definite  length  and  indefinite  length  are  supported.  Clipping  of  the 
image  can  be  specified.  Image  coding  may  be  according  to  ITU-TS  Recommendation  T.4  on 
facsimile.  Addition  of  JPEG  image  coding  will  be  in  a  second  part  of  the  standard.  There  are  not 
yet  any  JBIG  implementations.  [Ref.  Haber  1991]  A  third  standard  for  video  compression  has 
been  developed  by  the  Moving  Picture  Experts  Group  (MPEG). 

7.4.3  Moving  Picture  Experts  Group  (MPEG) 

ISO/IEC  JTC1  SC2/WG11  committee  work  on  MPEG  (ISO/IEC  11172)  began  in  1988 
with  the  goal  of  achieving  a  standard  by  1990.  The  parts  of  ISO/IEC  1 1 172,  Coding  of  Moving 
Pictures  and  Associated  Audio  far  Digital  Storage  Media  at  Up  to  about  1.5  Mbit/s,  are  as  follows 
[Ref.  LeGall  1991]: 

•  ISO/IEC  11172-1  (Part  1):  Systems,  August  1993 — addresses  synchronization  and 
multiplexing  of  multiple  compressed  audio  and  video  bit  streams 

•  ISO/IEC  11172-2  (Part  2):  Video,  August  1993 — addresses  compression  of  video 
signals  at  1.5  Mbits 

•  ISO/IEC  11172-3  (Part  3):  Audio,  August  1993 — addresses  compression  of  digital 
audio  signals  at  rates  of  64, 128,  and  192  kbit/s  per  channel 

•  CD  1 1 172-4  (Part  4):  Conformance  Testing,  November  1993  (DIS  expected  March 
1994,  IS  in  November  1994) 

•  WD  1 1172-5  (Part  5):  Technical  Report  on  Software  for  ISO/IEC  11172,  1993  (CD 
expected  March  1994,  DIS  in  July  1994,  and  IS  in  March  1995). 

Another  standard  with  similar  scope  to  MPEG  is  CD  13818,  Generic  Coding  of  Moving 
Pictures  and  Associated  Audio  Information,  with  the  following  parts: 

•  CD  13818-1  (Part  1):  Systems,  SC29/WG1 1,  November  1993  [SC29  N  634]  (DIS 
expected  March  1994,  IS  in  November  1994] 

•  CD  13818-2  (Part  2):  Video,  SC29/WG11,  November  1993  [SC29  N  634]  (DIS 
expected  March  1994,  IS  in  November  1994] 

•  CD  13818-3  (Part  3):  Audio,  SC29/WG11,  November  1993  [SC29  N  635]  (DIS 
expected  March  1994,  IS  in  November  1994] 

•  WD  13818-4  (Part  4):  Conformance  Testing,  SC29/WG11,  November  1993  [SC29 
N  63 6]  (CD  expected  November  1994,  DIS  in  March  1995,  IS  in  November  1995] 
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•  WD  13818-5  (Part  5):  Technical  Report  on  Software  for  ISO/IEC  13818, 
SC29/WG11  (WD  expected  July  1994,  CD  in  November  1994,  DIS  in  March  1995, 
IS  in  November  1995] 

•  WD  13818-6  (Part  6):  System  Extensions,  SC29/WG11  (WD  expected  November 
1994,  CD  in  March  1995,  DIS  in  November  1995,  IS  in  July  1996] 

•  WD  13818-7  (Part  7):  Audio  Extensions,  SC29/WG11  (WD  expected  November 
1996,  CD  in  March  1997,  DIS  in  July  1997,  IS  in  March  1998] 

7.4.4  Digital  Video  Interactive  (DVI) 

Digital  Video  Interactive  (DVI)  uses  a  proprietary  compression  scheme  that  is  backed  by 
Intel  Corporation,  IBM,  and  AT&T.  IBM  and  Intel  are  already  marketing  DVI  products  for 
personal  computers,  and  it  has  the  potential  to  become  a  de  facto  standard. 

7.4.5  Other  Activities  for  Data  and  Image  Compression 

Section  7.7  describes  the  MHEG  standard,  Coded  Representation  of  Multimedia  and 
Hypermedia  Information  Objects ,  CD  13522. 

PIK  Reference  Model  for  Image  Data.  ANSI  X3H3.8  has  defined  a  PIK  Reference 
Model  with  three  components:  functional  services,  object  data,  and  operational  models. 
Functional  services  are  classified  according  to  a  layered  model,  in  which  the  highest  layer  is  the 
application  and  the  lowest  layer  is  a  specific  implementation.  The  horizontal  dimension  in  the 
model  identifies  different  functionalities  present  at  the  same  layer.  The  object  data  correspond  to 
images  as  well  as  non-image  data  of  control  or  parameters  (e.g.,  look-up  table,  processing 
parameters).  Operational  models  group  together  different  methods  for  building  applications.  [Ref. 
RNLA  1994,  pp.  158-159] 

Adapting  Coding.  ANSI  X3  recently  announced  the  approval  of  a  new  project  on  Data 
Compression,  Adaptive  Coding  with  Sliding  Window  for  Information  Interchange  under  the 
auspices  of  Technical  Committee  ANSI  X3B5,  Digital  Magnetic  Tape.  This  standard  will 
represent  the  minimum  requirements  for  the  generation  of  a  compressed  encoding  of  data  for  the 
interchange  of  information  between  systems  and  provide  an  effective  encoding  that  results  in  the 
compression  of  data  typical  to  information  processing  systems.  [Ref.  X3  1991k] 

PDU  Compression.  Within  ISO,  the  Presentation  Rapporteur  Group  is  considering 
adding  support  for  compression  of  protocol  data  units  (PDUs)  within  the  presentation  protocol. 
Options  could  include  compression  of  the  complete  presentation  PDU,  compression  of  the 
complete  user  data  parameter  of  the  presentation  PDU,  or  a  selectable  transformation  to  be  applied 
to  the  encoding  of  an  individual  presentation  data  value.  [Ref.  SC21  N  6985  1992] 

Picture  Coding.  In  the  United  States,  ANSI  X3,  X3L3,  Audio/Picture  Coding,  has 
responsibility  for  picture  coding.  Some  relevant  ISO  standards  include: 

•  ISO  928 1,  Identification  of  Picture  Coding  Methods,  August  1990: 

Part  1:  Identification 

Part  2:  Procedure  for  Registration. 

•  ISO  9282,  Coded  Representation  of  Pictures: 

Part  1:  Encoding  Principles  for  Picture  Representation  in  a  7 -bit  or  8-bit 

Environment,  September  1988 

Part  2:  Encoding  Principles  for  Photographic  Images,  May  1992. 
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New  Work  Items  for  SC29.  SC29  projects  include  the  following  new  work  items: 

•  Image  Compression  Across  Multiple  Components  [SC29  N  363]  (WD  expected 
November  1995,  CD  in  November  1996,  DIS  in  July  1997,  IS  in  1998) 

•  Lossy/Lossless  Coding  of  Bi-level  Images  [SC29  N  364]  (WD  expected  November 
1995,  CD  November  1996,  DIS  in  July  1997,  IS  in  1998) 

•  Compression  of  Up  to  5-D  Images  [SC29  N  365]  (WD  expected  November  1995,  CD 
in  November  1996,  DIS  in  July  1997,  in  IS  1998) 

•  Lossless  Compression  of  Continuous-Tone  Still  Pictures  [SC29  N  366]  (WD  expected 
November  1995,  CD  in  November  1996,  DIS  in  July  1997,  IS  in  1998) 

•  Very-low  Bit  Rate  Audio-Visual  Coding  [SC29  N  367]  (in  four  parts:  Systems, 
Video,  Audio,  and  Conformance  Testing;  WD  expected  in  November  1996,  CD  in 
November  1997,  DIS  in  March  1998,  and  IS  in  November  1998) 

•  Low-Bit-Rate  Audio  Coding  [SC29  N  368]  (WD  expected  in  November  1995  and  CD 
in  November  1997) 

•  Coding  of  Man/Multimedia  Service  Interface  Standardization 

•  Interchange  of  Compressed  Pictures. 

Image  Compression  Initiatives.  The  following  initiatives  are  being  explored  for 
image  compression  [Ref.  RNLA  1994,  pp.  159-160]: 

•  Wavelets — an  image  compression  approach  validated  by  demonstration.  WSQ  is  a 
wavelet  standard  developed  in  the  United  States,  in  which  the  emphasis  is  on  quality 
and  high  compression 

•  Fractal  Compression — gives  ultra-high  compression  ratios  on  the  order  of  2500: 1  and 
gives  better  results  for  zooming  than  other  techniques.  Fractal  compression  can  be 
done  in  near-real  time  but  requires  powerful  workstations. 

•  X-Image  Extension  (XIEY — defines  an  X  extension  for  the  imaging  domain  and 
includes  a  selection  of  several  recognized  algorithms  and  techniques  for  color 
allocation,  compression,  dithering,  etc. 

•  Common  Mapping  Standard  (CMS)— a  standardized  cartographic  database  structure 
developed  by  the  US  Air  Force  for  mission  planning  systems,  providing  high-speed 
access  to  data  including  maps,  charts,  geodesy,  and  imagery.  CMS  requires 
preprocessing  from  DMA  standard  products. 

•  RADIUS  Common  Development  Environment  (RCDE) — part  of  the  Research  and 
Development  for  Image  Understanding  Systems  (RADIUS)  project  funded  by  the  US 
Advanced  Research  Projects  Agency.  RDCE  is  a  software  environment  for  the 
development  of  image-understanding  algorithms. 

•  ImageCalc — a  software  tool  developed  by  the  Artificial  Intelligence  Center  Perception 
Group  of  SRI  International.  It  provides  the  user  with  image  operators  and  interactive 
tools.  Its  internal  image  representation  efficiently  handles  manipulation  and  display  of 
large  (4,000  x  4,000-pixel)  images.  ImageCalc  runs  on  a  Lisp  machine  (Symbolics). 

7.5  Video  Data  Exchange 

Future  information  systems  will  depend  on  video  technology  for  multimedia  information 
exchanges,  training,  and  intelligence  gathering.  Information  systems  may  need  to  store  and 
transmit  such  video  images  to  analysts  at  distributed  locations.  [Ref.  IDA  1991,  p.  162] 

Most  of  the  standards  in  this  area  appear  to  have  come  from  the  television  industry, 
specifically,  in  the  United  States,  the  Society  of  Motion  Picture  and  Television  Engineers 
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(SMPTE).  The  International  Radio  Consultative  Committee  (CCIR)  Recommendation  601 . 
Encoding  Parameters  of  Digital  Televisions  for  Studios,  was  published  in  1982. 

nU-TS  Recommendation  H.261,  Video  Coder  for  Audiovisual  Services  at  px64  kbit/s 
(commonly  referred  to  as  the  px64  standard),  is  a  video  coding  standard  that  was  approved  in 
December  1990  A  slightly  modified  version  was  developed  by  ANSI  Tl.  It  is  T1.314,  Digital 
Processing  of  Video  Signals  -  Video  Coder/Decoder  for  Audiovisual  Services  at  56  to  1,536  kbit/s , 
published  in  1991. 

The  real-time  simulation  community  is  currently  faced  with  a  tradeoff  between  standards 
and  high-speed  performance  when  available  computing  power  is  inadequate  to  support  standards. 
MIL-STD-1379D,  Military  Training  Programs,  also  addresses  video,  as  does  Multi-Media 
Extensions  to  Microsoft's.  Windows  (de  facto). 

In  addition.  High  Definition  Television  (HDTV)  will  require  studio,  exchange,  mission, 
and  display  standards.  For  none  of  these  does  a  single  international  standard  seem  likely.  In  the 
United  States,  the  FCC  intended  to  issue  HDTV  standards  in  the  spring  of  1993.  The  FCC  action 
was  delayed,  however,  to  allow  competing  consortia  to  reconcile  their  differences.  As  of 
November  1993,  an  alliance  of  these  consortia  had  announced  key  technology  specifications  for 
digital  HDTV  sets  of  the  future.  The  alliance  comprises  three  teams  which  previously  had 
embraced  four  different  HDTV  systems: 

•  The  Advanced  Television  Research  Consortium  of  Phillips,  Thomson  Consumer 
Electronics,  the  David  Samoff  Research  Center,  Compression  Labs,  and  NBC 

•  The  team  of  Zenith  and  AT&T 

•  The  General  Instrument  and  Massachusetts  Institute  of  Technology  team. 

The  most  difficult  issue  they  settled  was  agreement  on  a  converter  that  makes  progressive 
and  interlaced  scanning  formats  work  in  one  system.  The  alliance  also  settled  on  a  5. 1-channel 
Dolby  AC-3  audio  technology  for  HDTV  sound,  a  video  compression  system  called  MPEG-2 
(which  improves  picture  quality),  and  a  packetized  data  transport  system  that  allows  the 
transmission  of  any  combination  of  video,  audio,  and  data.  [Ref.  HDTV  1993] 

7.6  Audio  Exchange  Standards 

Integrated  voice  technology  is  another  future  information  system  requirement  Some 
possible  applications  include: 

•  Voicemail 

•  Multimedia  documents  for  training  and  maintenance 

•  Computer-generated  speech  for  ”eyes-on"  situations.  [Ref.  IDA  1991,  p.  166] 

In  March  1991,  ANSI  X3  announced  the  approval  of  two  new  standards  projects  on  Voice 
Messaging: 

•  Voice  Messaging  over  MOTIS  ISO  10021  is  being  developed  by  Task  Group  ANSI 
X3V1.4  as  a  standard  protocol  for  voice  messaging  to  permit  the  interchange  of 
information  objects  effectively  between  various  vendors'  message  systems. 

•  Standard  User  Interface  to  Voice  Messaging  is  being  developed  by  Task  Group  ANSI 
X3V1.9  to  provide  users  of  voice  messaging  systems  with  a  consistent  mode  of 
interaction  in  a  way  that  is  independent  of  underlying  system  implementation.  The 
standard  will  apply  only  to  touch  tone  telephones.  Alternative  interface  technologies 
such  as  speech  recognition  or  screen-based  interfaces  are  not  included. 
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X3L3  also  has  a  Project  on  Coded  Representation  of  Audio  Information;  corresponding 
work  on  this  topic  has  been  cancelled  by  ISO  JTC1/SC27. 

The  ITU-TS  I-Series  recommendations  for  Integrated  Services  Digital  Network  (ISDN) 
(see  Section  9.7.6)  seeks  to  combine  audio,  video,  and  data  transmission  on  a  single  system. 
Currently,  the  service  is  limited  to  a  number  of  disconnected  areas  since  most  of  the  long  distance 
trunk  service  has  not  been  converted.  [Ref.  IDA  1991,  p.  166] 

The  ODA  (see  Section  7.1.1)  is  designed  tc  allow  for  extensions  including  additional  types 
of  content  such  as  sound.  In  addition,  ITU-TS  G.721  is  a  standard  audio  encoding  method. 

Standards  for  coding  of  moving  pictures  and  associated  audio  information  are  discussed  in 
Section  7.4.3  above. 

7.7  Multimedia  Standards 

An  issue  that  transcends  audio  or  video  data  exchange  alone  is  that  of  integrating  all  these 
nascent  standards  efforts  by  developing  a  framework  or  reference  model  for  digital  multimedia. 
This  problem  has  only  recently  been  considered  by  ISO/IEC  JTC1.  In  addition  to  algorithms,  bit 
streams,  encoders,  and  decoders,  both  users  and  application  programmers  will  need  complete 
systems  and  environments.  Open  systems  are  required,  each  with  an  interactive  multimedia 
application  development/utilization  environment,  including  some  or  all  of  the  following  [Ref. 
Fox  1991]: 

»  Multimedia  data  capture  tools 

•  Multimedia  data  editors/synthesizers 

•  Multimedia  scripting  language  tools 

•  Multimedia  data  integrator/sequencer  tools 

•  Multimedia  database  and  storage/retrieval  layout  tools 

•  User  interface  development  tools 

•  Simulation,  testing,  and  publishing  assistance  tools 

•  Archiving,  versioning,  backup,  and  recovery  tools 

•  Project  management  tools 

•  Run-time  support  environment  for  application  use. 

Developing  a  framework  is  but  one  suggestion  of  the  ISO/EEC  JTC1  Ad  Hoc  Technical 
Study  Group  on  Multimedia  and  Hypermedia.  Other  tasks  include: 

•  Discussing  and  recording  a  procedural  plan  for  establishing  multimedia  and 
hypermedia  requirements  and  a  procedure  for  communicating  these  requirements 
among  the  relevant  groups  within  JTC1 

•  Preparing  a  report  on  the  general  concepts  and  definitions  related  to  multimedia  and 
hypermedia  and  trying  tc  reach  agreement  on  general  concepts. 

SC18  has  been  given  the  responsibility  for  developing  the  framework.  In  October  1992,  it 
issued  a  Working  Drd$  of  the  Technical  Report  on  Multimedia  and  Hypermedia:  Model  and 
Framework  [SC21  N  7430,  November  1992].  SC18  will  work  closely  with  the 
Multimedia/Hypermedia  Experts  Group  (MHEG)  (JTC1  SC29/WG12)  in  developing  the  Audio 
Visual  Interactive  (AVI)  Scriptware  work  item  (JTC1  N  809)  as  a  two-part  standard  [Ref. 
JTC1N1161  1991]: 

•  Parti:  Functional  definition,  being  the  responsibility  of  SC  18 

•  Part  2:  Encoding,  being  the  responsibility  of  SC29. 
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In  1993,  another  MHEG  standard.  Coded  Representation  of  Multimedia  and  Hypermedia 
Information  achieved  CD  status  (CD  13322).  Its  parts  are  as  follows: 

•  CD  13522-1  (Part  1):  MHEG  Objects  Representation  -  Base  Notation  (ASN.I),  1993 
(DIS  expected  March  1994  and  IS  in  November  1994) 

•  WD  13522-2  (Part  2):  Alternate  Notation  (SMSL),  1993  (CD  expected  March  1994, 
DIS  in  November  1994,  and  IS  in  February  1995) 

•  WD  13522-3  (Part  3):  MHEG  Extensions  for  Scripting  Language  Support,  1993  (CD 
expected  December  1994,  DIS  in  June  1995  and  IS  in  December  1995). 

SC24  has  an  new  work  item  proposal  to  develop  a  Presentation  Environment  for 
Multimedia  Objects  (PREMO),  November  1992  [SC24  N  847].  PREMO  will  be  a  multi-part 
standard  that  will  address  all  aspects  of  the  construction  of,  presentation  of,  and  interaction  with 
multimedia  objects.  Multimedia  objects  include  computer  graphics,  moving  computer  graphics 
(animation),  synthetic  graphics  of  all  types,  text,  audio,  still  images,  moving  images  (including 
video),  images  coming  from  imaging  operations,  and  any  other  context  type  of  combination  of 
context  types  that  can  be  "presented."  Target  dates  are  CD  in  June  1994,  DIS  in  June  1995,  and  IS 
in  19%.  [Ref.  SC21  N  7642  1993] 

SC29  has  authorized  the  following  new  work  item:  Coding  of  Standard  Multimedia 
Scripting  Language  (SMSL),  for  which  WD  is  expected  February  1994,  CD  in  June  1994,  DIS  in 
December  1994,  and  IS  in  1995. 

In  March  1992,  ANSI  X3  announced  the  approval  of  a  new  project  on  Hypermedia  and 
Multimedia  Glossary,  an  addendum  to  ANSI  X3.172-1990.  [Ref.  X3  1992f]  Another  ANSI 
(X3L3)  project  is  Coded  Representation  of  Multimedia  and  Hypermedia  Information  Objects, 
Part  1:  Multimedia  Synchronized  Objects  and  Part  2:  Hypermedia  Objects. 

The  Interactive  Multimedia  Association  (IMA)  has  been  actively  promoting  industry-wide 
compatibility  of  multimedia  products.  In  1988,  the  IMA  Compatibility  Committee  was  formed  to 
develop  recommendations  for  multimedia  applications  that  would  permit  their  portability  across  a 
variety  of  hardware-software  platforms.  Recommended  Practices  for  Multimedia  Portability, 
Release  Rl.l,  was  published  October  1990.  It  recommends  commands  for  general  system 
services,  visual  management,  videodisc  players,  and  X-Y-input  devices.  The  recommended 
practices  furnish  platform  independence  but  not  device  interoperability. 

In  November  1990,  the  DoD  incorporated  the  IMA  specification  in  Appendix  D  of  MIL- 
STD- 1379.  In  March  1991,  the  DoD  issued  DoD  I  1322.20,  Development  and  Management  of 
Interactive  Courseware,  which  mandates  that  all  interactive  multimedia  courseware  and  hardware 
systems  purchased  by  the  DoD  must  comply  with  IMA  specifications.  [Ref.  Jurgen  1992] 

In  August  1993,  it  was  announced  that  an  international  group  of  vendors  has  set  out  to 
promote  the  design  and  use  of  collaborative  multimedia  applications,  which  use  video  conferencing 
and  other  techniques  to  allow  people  who  cannot  meet  face  to  face  to  work  together  from  any 
points  on  die  globe.  The  seven  founding  members  of  the  Multimedia  Communications  Community 
of  Interest,  BT,  France  Telecom,  Deutsche  Bundespost  Telekom,  IBM,  Intel,  Northern  Telecom 
and  Telstra,  have  invited  other  companies  to  join.  The  group  will  promote  applications  that  let 
people  in  different  locations  view  documents,  images,  graphics,  and  full-motion  videos  on  a 
personal  computer  screen,  discuss  what  they  see  on  the  screen,  and  make  changes  that  all  other 
participants  can  see.  This  must  be  possible  regardless  of  the  operating  system,  computer 
equipment,  or  telecommunications  company  being  used.  The  group  will  promote  the  use  of 
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existing  industry  standards,  and,  where  standards  do  not  exist,  will  define  working  specifications. 
A  series  of  field  trials  was  planned  to  begin  in  the  first  quarter  of  1994.  [Ref.  OSN  1993p] 
Section  9.11.4.2  also  addresses  some  X.400- related  computer  conferencing  and  asynchronous 
group  communication  standards  work. 

7.8  Assessment  of  Coverage  by  Standards 

Data  interchange  services  establish  data  formats  for  interchange  of  documents,  graphics 
data,  and  product  description  data. 

In  the  area  of  document  exchange,  standards  exist  that  would  fulfill  an  AIS's  requirements. 
There  is  evidence  that  these  standards  are  stabilizing  as  Document  Application  Profiles  (DAPs) 
begin  to  appear.  While  both  ODL  and  SGML  can  be  used  with  ODA  and  information  can  be 
transferred  between  the  two  formats,  there  are  some  advantages  to  using  SGML.  Not  only  does 
CALS  use  SGML,  but  more  commercial  products  are  available  for  it  than  for  ODL.  Moreover,  it  is 
human-readable,  preserves  user  file  divisions,  and  is  extensible  to  other  architectures.  It  also 
possesses  a  broader  information  processing  orientation  than  does  ODL,  which  is  concerned  solely 
with  document  processing.  ODA  (ISO  8613:1989)  models  are  still  incomplete,  and  there  is  still 
ongoing  work  on  die  connection  between  document  logical  structure,  layout,  and  content  Gaps  in 
ODA/ODIF  standards  (for  which  future  ISO  work  is  planned)  include:  revision  collection,  status, 
rationale,  and  author  information;  document  annotations;  automatic  content  generation  of  listings 
such  as  table  of  contents,  tables  of  figures,  indexes,  glossaries,  and  cross  references;  business 
charting;  data  in  documents,  such  as  spreadsheets;  exchange  of  hypertext-based  documents;  and 
exchange  of  documents  that  include  voice  and  audio  information. 

Central  to  CALS  is  the  use  of  EDI  (FIPS  161;  EDIFACT,  ISO  9735:1988;  X.12-1986; 
ITU-TS  X.435.1991)  for  business  data  interchange.  EDIFACT  and  X.12  differ  in  syntax  control 
segments,  data  segments,  and  data  elements.  The  various  versions  of  EDI  are  expected  to  merge 
(in  a  future  edition  of  ISO  9735)  and  to  use  X.400-1988  messaging.  An  argument  against  using 
the  CALS  standard  as  a  model  is  that  it  is  oriented  to  technical  weapons  systems  support 
documentation  which  may  not  be  appropriate  to  an  information  system. 

The  status  of  technology  in  the  area  of  data  interchange  is  such  that  standards  do  not  yet 
manage  information  as  a  database  where  content  is  encoded  and  structure  and  form  attached. 

IGES  is  suitable  for  engineering  data  but  does  not  include  all  interfaces  for  use,  such  as  the 
interface  between  the  data  specification  and  numerically-controlled  machining  tools.  STEP 
represents  complex  data  objects  (e.g.,  technical  diagrams  and  documents)  suitable  for  product 
development  (e.g.,  for  advanced  manufacturing  machines)  from  initial  concept  design  to 
manufacturing  and  product  support 

Graphics  services  standards  all  appear  to  be  stable  and  mature  with  a  high  level  of 
consensus  and  product  availability.  However,  none  address  the  question  of  distributed  graphics. 
A  common  intermediate  standard  is  needed  to  exchange  graphics  data  stored  on  different  platforms. 

The  remaining  data  interchange  standards  areas  (geographic,  data  compression,  video,  and 
audio)  are  far  less  stable  and  mature.  A  lack  of  standards  has  impeded  interoperability  among 
digital  cartographic  and  geographic  information  systems.  For  example,  SDTS  (FIPS  173)  has 
been  developed  for  transfer  of  digital  spatial  data  among  heterogeneous  computer  systems; 
however,  an  international  forum  (with  the  participation  of  the  US  Defense  Mapping  Agency)  has 
developed  an  alternative  specification,  DIGEST.  Agreement  on  such  a  standard  is  essential  to  the 
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interoperability  of  geographical  information  systems  (GISs)  and  between  GISs  and  other 
information  systems  (at  least  to  import  terrain  data  and  map  graphics).  An  information  system 
proponent  will  need  to  monitor  standards  developments  in  these  areas  as  well  as  in  the  area  of 
multimedia  standards  where  standards  are  generally  lacking.  For  example,  one  promising 
technology  that  has  been  crippled  by  a  lack  of  standards  is  multimedia  mail.  [Ref.  Borens tein 
1991] 

Data  compression  standards,  particularly  JPEG  and  MPEG  have  attracted  significant 
support,  but  the  future  has  been  clouded  by  other  vendors  claiming  to  have  substantially  improved 
technical  approach es  to  compression. 
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8.  GRAPHICS  SERVICE  STANDARDS 

This  chapter  reviews  standards  being  developed  for 
computer  graphics.  These  include  the  Computer  Graphics 
Reference  Model,  the  Graphical  Kernel  System  (GKS),  and 
Programmer's  Hierarchical  Interactive  Graphics  System 
(PHIGS).  The  Computer  Graphics  Metafile  (CGM)  and 
Computer  Graphics  Interface  (CGI)  are  discussed  in 
Sections  7. 2.2.2  and  7. 2.2.3,  respectively.  The  Image 
Processing  and  Interchange  (IPI)  standard  is  discussed  in 
Section  7. 2.2.4.  An  overview  of  the  status  of  key  standards  for 
graphics  services  is  given  in  Table  11. 

8.1  Reference  Model  for  Computer  Graphics 

As  noted  in  Section  7.2.2. 1,  the  Reference  Model  for  Computer  Graphics  (ISO  11072) 
defines  a  basic  architecture  and  consistent  terminology  for  computer  graphics.  It  addresses 
environment;  primitives;  geometry,  attributes,  and  aspects  of  primitives;  pictures;  collections; 
metafiles;  and  archives.  There  are  four  environments:  application  (to  which  an  application 
interfaces),  virtual,  logical,  and  physical  (to  which  the  user  interfaces).  [Ref.  RM  1989] 

8.2  Graphical  Kernel  System  (GKS) 

The  GKS  standard,  ISO  7942  (FIPS  120-1),  specifies  a  language-independent  nucleus  of  a 
graphics  system.  For  integration  into  a  specific  programming  language,  GKS  is  embedded  in  a 
language-dependent  layer  obeying  the  particular  conventions  of  that  language.  This  layer 
(technically  referenced  as  a  "binding")  has  been  defined  for  the  programming  language  Ada  in  ISO 
86S1-3,  based  on  the  Ada  Programming  Language  (ISO  8652).  It  has  also  been  defined  for  the 
programming  languages  FORTRAN  (ISO  8651-1),  Pascal  (ISO  8651-2),  and  C  (ISO  8651-4). 

GKS  is  considered  to  be  a  mature  and  stable  standard.  A  full  range  of  products  and 
automated  tools  based  on  GKS  has  been  available  from  various  vendors  for  5  or  more  years. 
However,  it  is  limited  to  two-dimensional  (2D)  graphics.  [Ref.  APP  1991, 41] 

A  three-dimensional  (3D)  version  of  GKS  is  being  developed  in  ISO.  The  purpose  of 
GKS-3D  is  to  specify  extensions  to  GKS  for  defining  and  viewing  3D  wire-frame  objects.  As 
such,  the  GKS-3D  documents  only  describe  additions  to  be  made  to  GKS. 

Table  11.  Status  Ovarvtaw  of  Kay  Graphics  Sarvica  Standards 
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The  GKS-3D  portions  of  the  GKS  standards  are: 

•  ISO  8805,  GKS  for  Three  Dimensions  (GKS-3D)  Functional  Description,  October 
1988,  and  ISO  8805/WDAD 1,  Addendum  1:  Name  Set  Addendum,  April  1987 

•  DIS  8806-1,  GKS-3D  Language  Bindings  -  Part  1:  FORTRAN,  November  1988 

•  DIS  8806-3,  GKS-3D  Language  Bindings  -  Part  3:  Ada,  1989 

•  ISO/IEC  8806-4,  GKS  3D  Language  Bindings  -  Part  4:  C,  1991 

•  ANSI  X3. 122.5,  GKS-3D  Language  Bindings  -  USP. 

One  of  the  major  design  goals  in  ISO  is  compatibility  between  GKS-3D  and  GKS.  The  2D 
primitives  of  GKS  can  be  seen  as  a  subset  of  the  3D  primitives  obtainable  via  GKS-3D.  This 
allows  a  GKS-3D  program  to  read  both  2D  and  3D  metafiles  (by  forcing  2D  primitives  to  the  z=0 
plane);  thus,  upwards  compatibility  is  being  sought 

A  GKS  test  service  is  available  at  NIST.  It  tests  for  conformance  to  FIPS  120-1.  NIST 
distributes  an  information  pack  from  which  the  client  conducts  a  pre-validation.  NIST  then 
conducts  on-site  testing  and  generates  a  test  report  [Ref.  Cugini  1992] 

8.3  Programmer's  Hierarchical  Interactive  Graphics  System  (PHIGS) 

The  standards  for  PHIGS,  include  language  landings  for  graphics  interfaces: 

•  ISO  9592-1,  PHIGS  -  Part  1:  Functional  Description,  and  ISO  9592-1/AMI:  PHIGS 
Plus  Support 

•  ISO  9592-2,  PHIGS  -  Part  2:  Archive  File  Format,  and  ISO  9592-2/AMI:  PHIGS 
Plus  Support 

•  ISO  9592-3,  PHIGS  -  Part  3:  Clear-Text  Encoding  of  Archive  File,  and 
ISO  9592-3/AM  1:  PHIGS  Plus  Support 

•  ISO  9592-4,  PHIGS  -  Part  4:  PHIGS  Plus 

•  ISO/IEC  9593-1,  PHIGS  Language  Bindings  -  Part  1:  FORTRAN  Binding 

•  DIS  9593-2,  PHIGS  Language  Bindings  -  Part  2:  Extended  Pascal 

•  ISO/IEC  9593-3,  PHIGS  Language  Bindings  -  Part  3:  Ada 

DAM  1:  Incorporation  of  PHIGS  Plus 

•  ISO/IEC  9593-4,  PHIGS  Language  Bindings  -  Part  4:  C,  1991. 

PHIGS  (FIPS  153)  is  a  full-functioned  specification  for  the  development  of  interactive 
two-  and  three-dimensional  graphics  applications  that  manage  hierarchical  database  structures 
containing  graphics  data.  Numerous  PHIGS  implementations  are  available  for  various 
hardware/software  platforms.  PHIGS  is  mature  and  relatively  stable.  No  changes  are  planned  in 
the  next  1  to  3  years.  Bindings  for  FORTRAN  and  Ada  have  been  adopted.  Bindings  for  C  and 
Pascal  are  under  development  A  new  standard,  PHIGS  Plus  (ISO  9592-4)  has  been  developed, 
which  adds  shading,  lighting,  and  other  advanced  graphics  programming  capabilities  that  were  not 
included  in  PHIGS.  Conforming  PHIGS  programs  will  be  able  to  execute  under  PHIGS  Plus 
with  no  change.  [Ref.  APP  1991,  p.  42]  PEX  is  discussed  in  Section  5.2.5. 

A  PHIGS  test  service  is  available  from  NIST  to  test  implementation  for  conformance  to 
FIPS  153.  It  is  currently  available  for  the  FORTRAN  binding.  Version  2  became  available  on 
October  1992.  [Ref.  APP  1992] 

8.4  Assessment  of  Coverage  by  Standards 

Graphics  services  standards  all  appear  to  be  stable  and  mature  with  a  high  level  of 
consensus  and  product  availability. 
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9.  NETWORK  SERVICE  STANDARDS 

In  general,  data  communication  involves  three  agents: 
processes,  hosts,  and  networks.  Processes  are  the  fundamental 
entities  that  communicate  and  execute  on  hosts  (computers), 
which  can  often  support  multiple  simultaneous  processes. 
Hosts  are  interconnected  by  networks,  and  the  data  to  be 
exchanged  are  transmitted  by  the  network  from  one  host  to 
another.  [Ref.  Stallings  1987,  pp.  14-15] 

The  purpose  of  this  chapter  is  to  identify  existing  and 
emerging  standards  for  network  services.  It  documents  inter¬ 
relationships  among  interfaces  and  standards  and  describes  how 
they  can  be  mixed  to  provide  the  desired  network  services.  The 
chapter  is  organized  as  follows: 

•  QSI  Reference  Model  (9.1) 

•  Govemment/railitary  requirements  for  OSI  (9.2) 

•  Physical  Layer  standards  (9.3) 

•  Data  Link  Layer  standards  (9.4) 

•  Local  area  network  (LAN)  technologies  (9.5) 

•  Broadband  technology  (9.6) 

•  Network  Layer  standards  (9.7) 

•  Transport  Layer  standards  (9.8) 

•  Session  Layer  standards  (9.9) 

•  Presentation  Layer  standards  (9. 10) 

•  Application  Layer  standards  (9.1 1) 

•  Internetworking  (9.12) 

•  Other  standards  and  issues  (9.13) 

•  Assessment  (9.14). 

9.1  OSI  Reference  Model 

ISO/IEC  has  developed  a  seven-layer  model  to 
implement  standards  for  network  services.  This  model,  called 
the  Open  Systems  Interconnection  (OSI)  Reference  Model, 
provides  a  common  basis  for  coordinating  standards  developed 
for  the  purpose  of  system  interconnection,  while  allowing 
existing  standards  to  be  placed  into  perspective  within  an  overall 
framework.  The  term  OSI  qualifies  standards  for  the  exchange 
of  information  among  systems  that  are  open  to  one  another  for 
this  purpose  by  virtue  of  their  mutual  use  of  the  applicable 
standards.  The  fact  that  a  system  is  open  does  not  imply  any 
particular  system  implementation,  technology,  or  means  of 
interconnection,  but  refers  to  the  mutual  recognition  and  support 
of  the  applicable  standards.  [ISO  7498]  This  section 
summarizes  the  elements  of  the  OSI  Reference  Model  upper  and 
lower  layer  structures. 
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ACSE 

182 
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180 
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Assessment 
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Connection  Orientation 
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178 
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152 
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152 

Frame  Relay 
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HOLD 
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Internetworking 
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JTM 

201 
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145 
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146 

MHS/MOTIS 
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196 

Multi- Peer  Data  Transmission 

225 
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Network  Layer  Standards 

158 

OSI  Reference  Model 
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Physical  Layer  Standards 

141 
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139 

Requirements 

140 

ROSE 
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RPC 
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RTSE 

185 

SESE 

179 

Session  Layer  Standards 
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SONET 

154 

TCP/IP 

164 

TFA 

223 

Time  Synchronization 

222 

Transport  Layer 

170 

X.25 
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XTP 
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The  OSI  Reference  Model  comprises  seven  functional  layers.  The  application, 
presentation,  session,  and  transport  layers  (Layers  7, 6, 5,  and  4,  respectively)  together  implement 
the  processing-related  functions  and  are  termed  the  upper  layers.  The  lower  layers — network, 
link,  and  physical  layers  (Layers  3, 2,  and  1,  respectively) — implement  the  communication-related 
functions.  Two  types  of  standards  are  defined  for  each  layer:  service  definition,  which  abstractly 
defines  the  externally  visible  service  provided  by  the  layer;  and  protocol  specification,  which 
defines  the  interactions  that  peer  entities  must  carry  out  in  order  to  provide  the  requested  layer 
service.  The  roles  and  primary  standards  for  each  layer  are  summarized  in  Table  12.  Both 
ISQftEC  and  mJ-TS  (X. 21 1-217,  X.224-227)  standards  are  cited. 

9.1.1  Service  Definitions  and  Protocol  Specifications 

The  major  aspects  of  services  and  protocols  may  be  described  as  follows  [Ref. 
Stallings  1993,  pp.  30-34]: 

•  Services.  An  OSI  service  definition  is  a  functional  description  that  specifies  what 
services  are  provided  but  not  how  the  services  are  provided.  The  details  of  how  the 
services  are  provided  may  differ  from  one  open  system  to  another  without  loss  of 
interoperability.  Thus,  the  focus  is  on  interfaces  between  layers  without  unduly 
constraining  developers  on  providing  (standard)  services  within  each  layer.  The 
services  between  adjacent  layers  in  the  OSI  architecture  are  expressed  in  terms  of 
primitives  and  parameters.  A  primitive  specifies  the  function  to  be  performed,  and  the 
parameters  are  used  to  pass  data  and  control  information.  The  actual  form  of  a 
primitive  (e.g.,  a  procedure  call)  is  implementation  dependent 

•  Protocols.  An  OSI  protocol  is  concerned  with  exchanging  streams  of  data  between 
peer  entities.  Characterized  as  consisting  of  a  sequence  of  blocks  of  some  bounded 
size,  protocol  data  units  (PDUs)  contain  control  information  used  to  coordinate  the 
joint  operation  of  two  entities  engaged  in  the  protocol.  In  addition,  some  of  the  PDUs 
contain  (encapsulate)  user  data  from  the  next  higher  layer.  However,  data  from  one 
layer  may  be  segmented  prior  to  encapsulation  by  the  next  lower  layer  and  will 
therefore  need  to  be  reassembled  by  the  peer  layer  on  the  receiving  system  before 
being  passed  to  the  next  higher  layer  in  the  receiving  system.  Reasons  for 
segmentation  include  limitations  on  block  size,  efficiency  of  a  smaller  PDU  size,  more 
equitable  access  to  communications  resources,  shorter  average  delay,  and  use  of 
smaller  buffers. 
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Table  12.  Roles  and  Standards  for  Services  snd  Protocols  of  OSI  Reference  Model 


(Applica¬ 

tion) 


(Presenta¬ 

tion) 


Layer  2 
(Data  Link) 


1903,  pp.  25-36 


1993,  pp.  11-12 


Role 


rovidea  services  to  users  of  the  OSI  environment; 
examples  include  transaction  server,  file  transfer  protocol, 
and  network  management;  service  elements  include 
association  control  (ACSE),  remote  transfer  (RTSE),  and 
remote  operations  (ROSE),  Transaction  Processing  User 
ASE 


Performs  generally  useful  transformations  on  data  to 
provide  a  standardized  application  interface  and  common 
communications  services;  examples  include  encryption, 
text  compression,  and  reformatting;  specifies  or, 
optionaly,  negotiates  the  way  information  is  represented 
for  exchange  by  application  entities  and  provides  the 
representation  (syntax  not  meaning)  of  (1)  data  transferred 
between  application  entities,  (2)  the  data  structure  that  the 
application  entities  use,  and  (3)  operations  on  the  data’s 
structure 


■-Tnn’rrrr 


control  structure  for  communication  between 
applications;  establishes,  manages,  and  terminates 
connections  (sessions)  between  cooperating  applications; 
allows  cooperating  applications  to  organize  and 
synchronize  conversation  and  to  manage  data  exchange; 
session  services  are  used  during  a  session  to  regulate 
dialogue  by  ensuring  orderly  message  exchange  on  the 
session  connection 


,  transparent  transfer  of  data  between  end 
points  (cooperating  session  entities);  provides  end-to-end 
error  recovery  and  flow  control 


Provides  upper  layers  with  indspendence  from  the  data 
transmission  and  switching  technologies  used  to  connect 
systems;  is  responses  for  establishing,  maintaining,  and 
terminating  connections  across  networks;  provides  packet 
routing  and  relaying  between  end  systems  on  the  same 
network  or  on  interconnected  networks;  provides  hop-by¬ 
hop  network  service  enhancements,  flow  control,  and  load 
leveling;  services  are  independent  of  the  distance 
iterating  interconnected  networks 


8649 

(X.217) 

RTSE;  ISO  9066-1 
(X.218) 

ROSE  ISO  9072- 
1  (X219) 

TP  User  ASE: 

ISO  10026 


8650 

PC227) 

RTSE;  ISO  9066-2 
()C228) 

ROSE  ISO  9072- 
2  (X.229) 
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a  physical  connection  for  transmission  of  data 
between  data  link  entities;  is  concerned  with  the 
transmission  of  an  unstructured  bit  stream  over  a  physical 
link;  involves  such  parameters  as  signal  voltage  swing  and 
bit  duration;  deals  with  the  mechanical,  electrical  (s.g., 
electrical  coding  and  decoding),  and  procedural 
characteristics  to  establish,  maintain,  and  deactivate  the 


ISO  8886  (X.212) 


IS0 10022  (X.211) 


Described  in 
separate  figure 
(see  Section  9.1.3) 


9.1.2  Status  of  OSI  Reference  Model  Standards 

Developed  in  1977  and  initially  published  by  ISO  in  1979,  the  OSI  Basic  Reference  Model 
became  an  ISO  standard  (ISO  7498)  in  October  1984.  ISO  JTC 1/SC21  has  a  standing  document 
(SD-9),  Approved  Commentaries  on  the  Basic  Reference  Model  for  Open  Systems 
Interconnection,  last  updated  in  December  1993  [SC21  N  8342].  The  following  extensions  have 
been  added  or  are  in  progress  [Ref.  Tang  1992,  pp.  17-18]: 
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•  ISO  7498  AD  1,  Connectionless  Mode.  The  original  OSI  model  was  connection- 
oriented,  meaning  that  die  communicating  parties  have  to  establish  a  logical  connection 
before  communication  can  take  place.  However,  there  is  a  demand  for  connectionless 
mode  communication  in  LANs,  network  management,  and  interactive  environments. 
ISO/IEC  7498- 1 : 1994  ( Basic  Reference  Model,  Part  1 :  General  Aspects)  incorporates 
this  addendum.  This  revision  addresses  upper  and  lower  layers,  and  it  permits  routing 
and  relaying  between  individual  local  networks  in  the  Data  Link  Layer.  It  also  clarifies 
the  distinction  between  connectionless  and  connection-mode  operation,  aligns  the 
service  definitions  for  the  lower  and  also  upper  layers,  improves  consistency  of  layer 
descriptions,  adds  Reset  as  a  facility  to  the  Data  Link  Layer,  adds  Suspend  and 
Resume  as  functions  in  the  Transport  Layer,  and  aligns  this  work  with  ITU-TS 
(X.200). 

•  ISO/1EC  7498-1:1994,  Basic  Reference  Model.  This  part  is  a  new  edition  of 
ISO  7498  that  creates  a  multi-part  standard  and  incorporates  AD  1.  IS  text  was 
available  in  November  1993  but  ITU-TS  approval  is  not  yet  complete  (balloting  ended 
February  1994). 

•  ISO  7498-2,  Security  Architecture,  February  1989.  This  part  defines  OSI  security 
architecture  as  an  enhancement  to  the  OSI  architecture.  It  describes  security 
architectural  concepts  such  as  security  services  and  security  mechanisms.  It  also 
outlines  how  security  services  can  be  placed  in  the  OSI  Reference  Model.  SC21 
proposed  confirmation  (continuance  as  a  valid  standard  without  revision)  of  this  part  in 
June  1993. 

•  ISO  7498-3,  Naming  and  Addressing,  March  1989.  This  part  defines  a  general 
mechanism  for  the  use  of  names  and  addresses  to  identify  and  locale  objects  in  an  OSI 
environment  (OSIE).  SC21  has  proposed  a  revision  incorporating  new  work  (Ql/68 
an  Ql/70)  on  naming  and  addressing. 

•  ISO/IEC  7498-4,  Management  Framework,  November  1989.  This  part  defines  a 
framework  for  management  activities  pertinent  to  OSI  and  management  services 
supported  by  the  OSI  management  protocols.  It  covers  the  management  concepts, 
management  functional  areas,  and  management  structure.  In  June  1993,  SC21 
proposed  confirmation  of  this  standard  with  the  addition  of  a  technical  corrigendum 
currently  in  the  form  of  a  defect  report  [SC21 N  6638]. 

•  WD  7498-5,  Architecture  for  Multi-Peer  Communications.  This  work  is  a  reactivation 
of  earlier  work  conducted  as  ISO  7498  PDAD  2  on  Multi-Peer  Data  Transmission 
(MPDT),  which  was  suspended  in  November  1989.  It  will  address  requirements  such 
as  multi-endpoint  connection  (see  Section  9.2.2).  Balloting  on  the  new  work  item 
proposal  was  successfully  completed  in  November  1993,  and  a  CD  is  expected  in 
1996. 

Related  Models.  The  Basic  Reference  Model  is  being  supplemented  by  a  number  of 
other  models  and  frameworks  within  the  context  of  OSI.  These  include  Application  Layer 
Structure  (ISO/IEC  9545),  Internal  Organization  of  die  Network  Layer  (ISO  8648),  Management 
Information  Model  (ISO/IEC  10165-1),  Upper  Layer  Security  Model  (ISO/IEC  10745),  Remote 
Procedure  Call  Model  (DIS  1 1578-1),  Generic  Upper  Layers  Security  (GULS)  Overview,  Models 
and  Notation  (DIS  11586-1),  Transaction  Processing  Model  (ISO  10026-1),  and  Remote 
Operations  Model  (CD  13712-1). 

Naming  and  Addressing.  TR  10730,  Tutorial  on  Naming  and  Addressing,  introduces 
the  main  concepts  and  mechanisms  that  are  defined  in  ISO  7498-3  to  fulfill  the  needs  for  naming 
and  addressing  objects  in  the  OSI  environment.  It  also  includes  the  rationale  for  some  of  the 
important  decisions  made  in  the  naming  and  addressing  architecture.  An  amendment,  TR  10730 
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WDAM  1,  Directory  Names ,  is  in  progress  but  is  dependent  on  progression  of  an  amendment  to 
ISO/IEC  9834-1  on  registration  authorities  (see  Section  12.3).  In  addition,  SC21/WG1  proposed 
in  May  1992  a  new  question  (Ql/68)  on  the  definition  of  the  term  application-process-title.  This 
term  is  introduced  in  ISO  7498-3,  but  not  formally  defined.  A  need  has  arisen  to  reference  such  a 
definition  from  ISO  9834-6.  The  definition  that  was  proposed  was  “a  name  that  is  used  to  identify 
unambiguously  an  application-process”  [Ref.  SC21  N  7094  1992].  ISO  7498-3  is  being  revised 
to  include  Ql/68. 

Two  documents  are  maintained  as  references  on  standard  definitions  for  OSI  vocabulary. 
SC21  has  an  internal  document.  Collections  of  Definitions  of  OSI  Vocabulary,  last  updated  in 
July  1992  [SC21  N  7268].  A  formal  standard  developed  by  JTC1/SC1  is  DIS  2382-26, 
Vocabulary ,  Part  26:  Open  Systems  Architecture,  January  1992. 

In  January  1992,  the  Conference  of  NATO  Armaments  Directors  (CNAD),  upon  the 
recommendation  of  the  NATO  Communications  and  Information  Systems  Committee  (NACISC), 
designated  the  NATO  Integrated  Communications  System  Central  Operational  Authority  (NICS 
COA)  as  the  NATO  OSI  Registration  Authority  for  naming  and  addressing.  [Ref.  CNAD  1992; 
NACISC  1992a] 

Related  Standards.  SC21  has  developed  guidance  for  users  and  definers  of  service 
standards.  The  initial  work  was  released  as  a  technical  report,  ISO/TR  8509,  Service 
Conventions,  September  1987.  A  more  comprehensive  standard  to  replace  the  technical  report  is 
ISOTEC  10731,  Conventions  for  the  Definition  of  OSI  Services,  1993  (ITU-TS  ballot  closed  in 
November  1993).  ISO  10731  consists  of  three  parts:  General  Model  and  Conventions, 
Application  Layer,  and  Layers  1-6. 

Several  architecture-related  topics  are  discussed  elsewhere.  As  noted,  security  is  addressed 
in  Section  11.2,  quality  of  service  (QoS)  and  OSI  management  in  Section  12.1,  and  formal 
description  techniques  (FDTs)  and  conformance  testing  in  Section  12.2.  Open  system 
environments  are  discussed  in  Section  15.1.3  and  15.3,  and  application  programming  interfaces 
(APIs)  are  treated  in  Section  15.2.  International  standardized  profiles  (ISPs)  are  discussed  in 
Section  16.1.2. 

9.1.3  Overview  of  OSI  Base  Standards 

Figure  6  provides  an  overview  of  the  standards  applicable  to  each  layer  of  the  OSI 
Reference  Model.  The  layer  OSI  standards  are  connected  by  vertical  lines  to  depict  a  ’vide  range  of 
stacks  for  application  (upper  layer)  and  transport  (lower  layer)  options.  Security  is  covered  in 
Chapter  11;  and  registration  authorities,  conformance  testing,  and  other  standards  applicable  to  all 
the  classes  of  services  are  identified  and  discussed  in  Chapter  12— these  are  not  included  in 
Figure  6. 

The  types  of  transfer  service  options  are  identified  along  the  bottom  of  Figure  6.  Standards 
and  options  in  a  layer  common  to  several  stacks  are  shown  in  blocks.  For  example,  the  Logical 
Link  Control  (LLC)  in  Layer  2  is  common  to  stacks  for  all  types  of  LANs  shown  in  Figure  6. 
Above  the  LLC,  the  CO-mode  X.25  Packet  Level  Protocol  (PLP,  ISO  8208,  8878,  8880-1, 
8880-2,  and  8881),  and  the  connectionless  network  protocol  (CLNP)  apply  to  each  of  the  four 
LAN  options.  The  X.25  PLP  (ISO  8208  and  8878)  in  Layer  3  and  the  High-Level  Data  Link 
Control  (HDLC)  in  Layer  2  are  required  for  the  stacks  for  four  types  of  circuits:  Circuit  Switched 
Data  Network  (CSDN),  Packet  Switched  Data  Network  (PSDN),  Point-to-Point  Subnetwork,  and 
Switched  Telephone  Network  (STN). 
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Appendixes  D  and  E  provide  a  complete  list  of  OS1  (and  other)  standards  developed  by 
ISQflEC  and  ITU-TS.  Appendix  D  is  organized  by  layer  of  die  OSI  Reference  Model  and  contains 
brief  tides,  whereas  Appendix  E  is  a  numerical  listing  that  contains  full  titles,  dates,  and  comments 
on  anticipated  completion  of  draft  documents. 

9.1.4  Connection  Orientation  for  OSI 

One  of  the  important  issues  that  must  be  considered  when  reviewing  OSI  standards  is  the 
choice  between  connection-oriented  (CO)  services  (also  called  "virtual  circuit"  services)  and 
connectionless-mode  (CL)  services  (also  called  "datagram"  services).  Each  of  the  seven  OSI 
layers,  except  the  Physical  Layer,  may  be  CO  or  CL.  (The  Physical  Layer  has  no  connection 
orientation.)  Hie  OSI  Reference  Model  recommends  that  the  upper  four  layers  be  either  all  CO  or 
all  CL.  The  following  paragraphs,  based  on  [Ref.  Purton  1987;  Stallings  1985, 1987a,  and  1993; 
and  NATO  1987],  address  some  prominent  distinctions  between  these  two  classes  of  services. 

With  connection-mode  transmission,  a  logical  connection  is  set  up  between  peer  entities 
prior  to  the  exchange  of  data.  This  connection  allows  both  sides  to  maintain  state  information 
about  the  history  and  current  status  of  the  transmission  of  protocol  data  units  between  the  two 
sides.  In  CL  operation,  each  data  unit  transmitted  is  independent  of  previous  or  subsequent  data 
units,  and  no  connection  is  set  up.  Table  13  contrasts  the  characteristics  of  the  two  modes.  [Ref. 
Stallings  1993,  p.  41] 


Table  13.  Characteristics  of  Connection-Hods  and  Connscttonlsss-Mods 

Data  Transmission 


t i\mi  i  k-m 

lit,’ :  :  :i  i  .ns  \ 

1  k :*Wi!*!ii  'kIi  .'(i 

i.  i  i— — — 

S«fl -contained  data  units  with  swvice  access 
point* 

Some*:  [Suiting*  1983.  p.  41]. 

The  basic  difference  between  CO  and  CL  service  is  that  CO  service  requites  that  an  explicit 
relationship  be  established  between  the  interacting  peer  entities  before  any  further  activity  can  take 
place,  while  in  CL  service  no  such  explicit  relationship  occurs.  A  connection  preserves  the  state  of 
peer-to-peer  communications  from  one  data  transfer  to  the  next,  storing  and  distributing 
information  regarding  the  connection  within  the  service  provider,  while  the  CL  transmission  does 
not  In  CO  service  the  relationship  may  be  real — such  as  a  dedicated  circuit— or  virtual,  such  as  a 
particular  path  from  node  to  node  between  peer  entities  in  a  CO  packet-switched  service.  In  the 
latter  case  the  path  would  be  agreed  upon  before  data  transfer  begins  and  would  remain  unchanged 
during  the  transfer.  A  heuristic  example  of  CO  service  is  any  national  public  telephone  service;  the 
regular  delivery  postal  service  is  a  heuristic  example  of  a  CL  service. 
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APPLICATION 

SERVICES: 


TELEMATIC 

SERVICES 


MESSAGE  HANDLING 


TELE- 

TEXT- 

TELE- 

TEX 

FAX 

FAX 

T.60 

T.72 

T.5 

T.81 

T.61 

T.6 

T.8 

T.73 

T.73 

[ 

[ 

T.62 

MHS 

(88) 

X400 

S«riM 

(1988) 


MOTIS 
ISO  10021 


OTHER  APPLICATIONS 

Directory^ ISO  9594 
File  Transfer  (FTAM):  ISO  8571 
Job  Transfer  (JTM):  ISO  8831, 8832 
Virtual  Terminal  (Vr):  ISO  9040, 9041 
Office  Document  Architecture:  ISO  8813 
Remote  Data  Access  (RDA):  ISO  9579 
Transaction  Processing  (TP):  ISO  10026 
Manufac.  Meg  Spec  (MMS):  ISO  9506 


Association  Control  Service  Element  (ACSE) 
CO:  ISO  8650;  CCR:  ISO  9805 


RPC:  DIS  11578;  RTSE:  ISO  9066;  ROSE:  ISO  9072 


CO:  ISO  8823 


ASCE 

CL 

IS0 10025 


CL  ISO  9576 


ASN.1:  ISO  8824;  ASN.1  Encoding:  ISO  8825 


T 

LAYER  4 
TUMI 


• 

LAYER  2 

CMaLM 

• 

LAYER  1 

CO:  ISO  8327 


CO:  ISO  8073;  CL  ISO  8602 


CO:  9574.8878.8208 
CL  8473.9542 


CONS 

X.25PLP 

ISO  8206 
ISO  8878 
ISO  8881 
ISO  8880-1 
ISO  8880-2 


CL  ISO  9548 


X25HDLC 

ISO  3309  ISO  7776 

ISO  4335  ISO  8471 

ISO  7809  ISO  8885 

ISO  7478  ISO  8880 

T.7Q/X.25  T.71 


See  Note  (1) 


Connectionless  Network 
Protocol  (CLNP) 

ISO  8473,  ISO  8880-1,  ISO  8880-3, 
ISO  9542 


Logical  Link  Control  (LLC)  ISO  8802-2. 8881 


1.430 

1.431 

1.460-1.464 
ISO  8877 


ISO 

8802-4 


.  ISO 
9314 


Local  Are^MetropoHtan  Area  Networks  (See  Notes  4, 5) 


CSDN  PSDN  Point-to-Point  PSTN  ISDN  Local  AreWMetropoKtan  Are* 

Subnetwork 
Layer  1  Standards  are: 

(a)  CSDN/PSDN:  V.24,  V.28,  V.35,  V.36,  V.37;  X21 ,  X21  bis,  X22,  X24,  X26,  X.27 

(b)  Point-to-Point  Subnetwork:  Predefined 

(c)  PSTN:  V.10,  V.11.  V.20,  V.24,  V.28,  V.31,  V.31bis,  V.35,  V.36,  V.37 


Standards  are  ITU-TS  unlesa  designated  ISO,  DIS. 
Stacks  are  based  on  series  1993  NOSIP  Strategy, 
are  omitted  from  NOSIP). 


Stacks  are  based  on  series  1993  NOSIP  Strategy.  (JTM,  MMS,  Token  Ring,  LAN,  and  Slotted  Ring  LAN 


Each  LAN/MAN  standard  addresses  both 
Interworking  standards  include  10028  (Ml 


rd  addresses  both  Layer  1  and  Layer  2  Media  Access  Control  (MAC)  for  Layer  2. 
include  10028  (MAC  Bridging),  and  10028, 10029  (Routing) 


Figure  6.  Stacks  of  OSI  Base  Standards 
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CO  service  has  three  phases:  connection  establishment  (set  up),  data  transfer,  and 
connection  release  (call  termination).  The  route  of  each  data  packet  is  determined  by  the  state  of  the 
network  during  the  call  set  up  and  remains  static  for  the  duration  of  the  connection.  Since  the  state 
information  is  maintained  for  each  established  connection  and  the  route  o i  data  packets  is  static,  the 
data  units  are  freed  from  the  requirement  to  carry  the  full  address  of  the  required  destination.  The 
CO  explicit  relationship  is  established  during  the  negotiation  portion  of  the  set-up  phase  and  before 
the  transfer  phase.  CO  service  provides  for  negotiation  of  the  form  of  transmitted  data  and  may 
maintain  sequence  and  flow  control.  Error  handling  may  also  be  supported.  The  overhead 
invested  in  setting  up  and  maintaining  a  CO  connection  pays  off  when  the  data  transfer  phase  is 
relatively  long.  The  1TU-TS  Recommendation  X.2S  for  interfacing  to  a  packet  switching  wide 
area  network  (WAN)  is  an  example  of  a  CO  protocol. 

In  contrast,  CL  service  has  only  one  phase — namely,  data  transfer.  The  form  of  the  data 
transferred  must  be  pre-arranged  between  peer  entities.  Sequencing,  flow  control,  and  error 
handling  are  not  supported  by  the  CL  service,  but  are  instead  the  responsibility  of  the  interacting 
peer  entities.  Sometimes  referred  to  as  a  “datagram”  service,  CL  service  requires  each  data  unit  to 
be  self-contained;  there  is  no  relationship  between  individual  data  unit  transfers. 

The  goal  of  the  OSI  Reference  Model  is  to  limit  the  amount  of  a  priori  information 
exchanged  between  end  systems  regarding  services  used  to  communicate,  which  is  best  met  by 
limiting  the  mixing  of  service  modes.  The  following  ISO/IEC  standards  for  the  four  cases  of 
connection  orientation  of  the  transport  and  network  services  are: 

•  ISO  8602  for  CL  transport  and  CL  network 

•  ISO  8602  for  CL  transport  and  CO  network 

•  ISO  8073  for  CO  transport  and  CO  network 

•  ISO  8073  for  CO  transport  and  CL  network. 

The  many  resulting  combinations  of  service  are  useful  in  different  circumstances.  CL 
service  may  be  appropriate  for  military  applications  that  require  robust  networks  capable  of 
continuing  data  transfer  even  as  some  nodes  are  taken  out  of  service,  especially  for  the  lower  layers 
(network  and  data  link).  [Ref.  Purton  1987  and  Stallings  1987a]  give  some  additional  examples  of 
cases  for  which  CL  service  is  appropriate,  even  for  the  upper  layers.  Included  are  inward  data 
collection  from  the  sampling  of  data  sources,  broadcast  messages,  some  distributed  transactions, 
some  real-time  transmission  applications,  and  cases  in  which  one  or  more  communicating  peers  are 
mobile.  In  general,  CO  service  is  beneficial  when  long-lived  connections  with  extensive  data 
transfer  are  anticipated.  File  Transfer,  Access,  and  Management  (FT AM)  is  an  example  of  an 
application  that  would  likely  benefit  from  a  CO  connection. 

The  cases  in  which  Layers  2  through  7  are  all  either  CO  or  CL  are  more  straightforward 
than  cases  with  upper  and  lower  layers  of  different  orientation.  If  CL  upper  layers  operate  over 
CO  lower  layers,  the  full  functionality  of  the  lower  layers  is  not  employed;  the  application  in  this 
case  does  nt  t  enjoy  the  amenities  of  CO  service. 

The  OSI  standards  supporting  CO  service  were  the  first  to  be  developed  and  are  nearly 
complete.  Until  recently,  standards  supporting  the  lower  layer  CL  service  were  more  advanced 
than  those  supporting  upper  layer  CL  services.  CL  protocols  for  the  Transport  Layer  (ISO  8602), 
Session  Layer  (ISO  9548),  and  Presentation  Layer  (ISO  9576)  are  complete. 

Choice  of  connection  orientation  affects  the  structure  of  the  Network  Layer  and  to  some 
degree  the  performance  of  services  in  the  Network  and  Transport  Layers.  According  to  ISO  8648, 
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Internal  Organization  of  the  Network  Layer,  the  Network  Layer  is  divided  into  three  sublayers. 
From  top  to  bottom  they  are  the  Subnetwork  Independent  Convergence  Protocol  (SICP),  the 
Subnetwork  Dependent  Convergence  Protocol  (SDCP),  and  the  Subnetwork  Access  Protocol 
(SAP).  This  structure  is  preferred  by  many  European  countries.  In  a  CL  network,  the  Network 
Layer  is  divided  into  two  sublayers:  Internetwork  Protocol  (IP)  and  Subnetwork  Specific  Protocol 
(SSP),  where  the  IP  focuses  on  unreliable  internetwork  transfer  of  information  while  the  SSP 
focuses  on  the  reliable  transfer  of  individual  data  units  across  the  supporting  networks.  The  CL 
approach  is  favored  by  the  United  States  [compare  the  OSI  profiles  recommended  by  the  United 
Kingdom  and  the  United  States  given  in  Section  16.1.3,  noting  that  ISO  Class  4  Transport 
Protocol  (TP4)  provides  services  for  CL  networks].  In  the  CL  model,  end-to-end  responsibilities 
are  placed  in  the  network  sublayers,  whereas  in  the  CO  approach  the  end-to-end  requirements  are 
placed  in  the  Transport  Layer.  One  drawback  of  using  TP4  over  a  CO  network  is  the  size  and 
complexity  of  the  implementing  code.  For  this  and  other  reasons,  many  implementors  of  CO 
stacks  do  not  support  TP4.  Section  6  of  [Ref.  NATO  1987]  provides  an  analysis  of  the  impact  of 
the  choice  of  CL  or  CO  mode  on  the  interconnection  of  heterogeneous  military  networks. 

Architectural  issues  being  developed  in  NATO,  including  those  on  connection  orientation, 
are  discussed  in  Section  18.9.3. 

9.1.5  Quality  of  Service  for  OSI 

Quality  of  service  (QoS)  is  the  collective  name  given  to  a  set  of  parameters  associated  with 
data  transmission  between  two  peer  service  users,  defining  the  quality  of  the  service  obtained 
during  the  exchange  of  data.  Not  all  QoS  parameters  apply  to  all  levels  and  some  are  dependent  on 
whether  the  service  provided  is  connection-mode  or  connectionless-mode  operation.  Some  are 
subject  to  negotiation  at  the  time  of  connection  set-up  and  some  are  specified  a  priori.  [Ref. 
Stallings  1993,  p.  43]  This  is  indicated,  in  part,  by  Table  14. 


Table  14.  Use  of  OSI  Quality  of  Service  Parameters 


Quality  of  Service  Parameter 
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Key:  t:  Configured  or  selected  prior  to  connection  establishment. 
N:  Negotiated  on  a  per-connection  basis. 

P:  Parameter  passed  down  to  next  lower  layer. 


Source:  [Stallings  1993,  p.  44]. 
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9.2  Government/Military  Requirements  for  OSI 

NATO  and  many  national  agencies  have  hundreds  of  disparate  information  systems  that  are 
not  interconnected  and  that  include  products  from  various  vendors.  The  resulting  heterogeneous 
environment  may  exhibit  a  high  degree  of  incompatibility  in  terms  of  hardware,  software,  data,  and 
communications.  This  incompatibility  often  leads  to  problems  such  as  inefficiency,  poor 
performance,  high  expense,  as  well  as  inhibiting  interoperability.  The  NATO  OSI  Profile 
(NOSIP)  Strategy  [Ref.  NATO  1993]  and  many  national  government  OSI  profiles  (GOSIPs)  have 
been  developed  to  address  these  problems  and  are  based  on  the  standards  shown  in  Figure  6 
(above).  These  profiles  (see  Section  16.1.3)  define  and  describe  a  common  set  of  data 
communications  protocols  that  enable  systems  developed  by  different  vendors  to  interoperate  and 
enable  the  users  of  different  applications  on  these  systems  to  exchange  information. 

9.2.1  Government  Requirements  for  OSI 

GOSIP  is  to  be  used  by  national  agencies  including  defence  communities  when  acquiring 
computer  network  products  and  services  and  communications  systems  or  services  that  provide 
equivalent  functionality  to  the  protocols  defined  in  GOSIP  documents.  In  some  cases  (e.g.,  the 
United  States),  agencies  will  be  permitted  to  buy  network  products  in  addition  to  those  specified  in 
GOSIP  and  its  successor  documents.  Such  products  may  include  other  non-proprietary  protocols, 
proprietary  protocols,  and  features  and  options  of  OSI  protocols  that  are  not  included  in  GOSIP. 

9.2.2  Military  Requirements  for  OSI 

During  the  past  8  years,  NATO  and  the  Nations  have  been  assessing  a  number  of 
deficiencies  in  the  emerging  OSI  standards  that  need  to  be  addressed  for  military  needs.  The  eight 
deficiencies  being  addressed  in  TSGCE  SG9  are  (see  Chapter  17  for  definitions): 

•  Multimode,  mobile  host  systems 

•  Multi-endpoint  connection 

•  Internetworking 

•  Network/system  management  functions 

•  Security 

•  Robustness  and  quality  of  service 

•  Precedence  and  preemption 

•  Real-time  and  tactical  communications. 

With  respect  to  the  eighth  military  feature,  Real-time  and  Tactical  Communication,  MITRE 
developed  a  proof-of-concept  prototype  system  to  test  the  applicability  of  GOSIP  protocols  in  the 
tactical  environment  and  concluded  that  the  full  OSI  protocol  stack  could  be  used  for  tactical 
messages  if  the  use  of  OSI  Congestion  Avoidance  is  required  and  the  number  of  Message  Transfer 
Agents  (MTAs)  that  must  be  traversed  is  minimized.  In  addition,  the  architectures  of  the 
implementations  must  focus  on  efficient  queue  handling  and  connection  handling.  [Ref. 
Messing  1990] 

Other  efforts  underway  to  evaluate  potential  OSI  performance  for  tactical  systems  include  a 
MITRE  traffic  study  [Ref.  Galitzer  1991]  using  loads  of  the  US  Maneuver  Control  System  (MCS) 
traffic  found  in  the  MCS  Segment  Specification.  Experiments  were  conducted  that  evaluated  traffic 
between  command  posts  and  internal  command  post  traffic  between  maneuver  control  and  other 
battlefield  functional  areas  (e.g.,  fire  support).  All  of  the  experiment's  messages  were  sent  with 
normal  priority  and,  at  600-bps  delivery  rates,  all  messages  arrived  in  15  minutes.  Separate  woik 
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done  by  McArthur  and  Bryant  [Ref.  McArthur  1991]  found  that  overhead  generated  by  X.400 
could  seriously  affect  retd-time  and  near-real-time  tactical  applications  on  low-bandwidth  networks. 
For  an  example  message  with  seven  recipients,  3,532  octets  (28,256  bits)  of  overhead  were 
required.  The  authors  note  that  overhead  may  be  reduced  by  more  efficient  encoding  or  more 
se?  jctive  use  of  X.400  parameters  and  concluded  that  it  appeared  that  X.400  is  not  well  suited  for 
tactical  applications  that  require  real-time  or  near-real-time  responses. 

ISO  SC21/WG1  is  still  refining  the  OSI  Reference  Model  regarding  die  specification  of  die 
boundaries  of  Layers  1  and  2.  Some  of  the  protocols  needed  for  the  communications  services  may 
be  determined  to  lie  outside  the  Reference  Model.  These  might  include  forward  error  correction 
coding36  (several  ISO  standards  provide  for  error  detection)  and  other  mechanisms  such  as 
interleaving  of  bits  from  a  sequence  of  octets  to  reduce  the  impact  of  the  environment  on  certain 
transmission  media.  Protocols  for  handling  requirements  of  cryptographic  devices  (e.g., 
synchronization)  and  media  access  may  also  lie  outside  the  Reference  Model.  Standardization  of 
these  features  should,  wherever  possible,  be  accomplished  with  media-independent  standards. 

9.3  Physical  Layer  Standards 

The  physical  layer  covers  the  physical  interface  between  devices  and  the  rules  by  which  bits 
are  passed  from  one  to  another.  The  physical  layer  has  four  important  characteristics  (taken  from 
[Stallings  1993,  p.  37]):37 

•  Mechanical,  relating  to  the  physical  properties  of  the  interface  to  a  transmission 
medium.  Typically,  the  specification  is  of  a  pluggable  connector  that  joins  one  or 
more  signal  conductors,  called  circuits. 

•  Electrical,  relating  to  the  representation  of  bits  (e.g.,  in  terms  of  voltage  levels)  and  the 
data-transmission  rate  of  bits. 

•  Functional,  specifying  the  functions  performed  by  individual  circuits  of  the  physical 
interface  between  a  system  and  die  transmission  medium. 

•  Procedural,  specifying  the  sequence  of  events  by  which  bit  streams  are  exchanged 
across  the  physical  medium. 

The  physical  layer  differs  from  other  OSI  layers  in  that  it  cannot  rely  on  a  lower  layer  to  transmit  its 
protocol  data  units  (PDUs);  rather,  it  must  make  use  of  a  transmission  medium  whose 
characteristics  are  not  part  of  the  OSI  model.  Because  local  area  network  (LAN)  standards 
explicitly  specify  the  physical  media  permitted  for  operation,  the  LAN  standards  are  included  in 
Part  II  (Physical  Layer  Standards)  of  Appendix  D. 

9.3.1  Communication  Medium 

Most  digital  data  processing  devices  possess  limited  data  transmission  capability. 
Typically,  they  generate  a  simple  form  of  digital  signal  known  as  NRZ  (nonreturn  to  zero),  in 
which  a  binary  “1”  is  represented  by  a  voltage  pulse  of  constant  amplitude,  and  binary  “0”  is 
represented  by  a  voltage  pulse  of  another  amplitude.  Such  signals  can  be  transmitted  only  over 
certain  types  of  transmission  media  and  over  very  limited  distances.  [Ref.  Stallings  1993, 
pp.  48-49] 


36  Whether  forward  error  correction  (FEC)  is  outside  of  the  OSI  Reference  Model  is  still  a  contentious  issue  in  ISO 
and  NATO.  Valid  arguments  exist  for  FEC  at  either  Layer  lor  Layer  2. 

37  The  Physical  Layer  standards  identified  in  Appendix  D  (Pat  H)  are  arranged  in  these  four  groups. 
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The  types  of  media  used  as  transmission  medium  are:  twisted-pair  cable,  coaxial  cable, 
fiber-optics,  and  microwave  radio. 

9.3.2  Twisted-Pair  Cable 

TWisted-pair  cable  is  typically  used  for  connecting  point-to-point  devices.  The  phone-wire 
approach  to  data  cabling  is  often  referred  to  as  unshielded  twisted-pair  wire.  Usually  consisting  of 
four  pairs  of  24-gauge,  color-coded  wires,  it  is  the  basis  of  new  cabling  provided  to  offices  in 
today’s  voice-and-data  wiring  systems.  In  terms  of  quality,  twisted-pair  wiring  used  for 
telephones  may  not  be  equally  capable  as  compared  to  the  wiring  used  for  data  communications. 
Typical  data  rates  vary  from  36  kbps  (thousands  of  bits  per  second)  to  1  Mbps  (millions  of  bits  per 
second),  though  new  technology  is  pushing  the  upper  limit  for  twisted-pair  cable  to  10  Mbps. 
(Ref.  Cemy  1991,  p.  167] 

9.3.3  Coaxial  Cable 

Coaxial  cable  comes  in  a  wide  variety  of  types  covering  a  broad  range  of  applications. 
Coaxial  cable  can  be  well  shielded  or  poorly  shielded;  it  can  be  thin  and  flexible  or  thick  and  rigid. 
The  usable  bandwidth  for  coaxial  cable  can  be  as  high  as  350  Mbps.  This  potentially  high 
bandwidth  can  be  utilized  in  one  of  the  two  ways  [Ref.  van  der  Jagt  1991,  p.  139]: 

•  Baseband  mode ,  in  which  all  the  available  bandwidth  is  used  to  derive  a  single  high  bit 
rate  (10  Mbps  or  higher)  on  the  transmission  medium. 

•  Broadband  mode,  in  which  the  available  bandwidth  is  divided  to  derive  a  number  of 
lower  bandwidth  subchannels  (and  hence  transmission  paths)  on  a  single  cable.  The 
amount  of  bandwidth  required  for  each  channel  is  determined  by  the  desired  data  (bit) 
rate  and  the  type  of  modulation  method  utilized,  typically  between  0.23  and  1.0  bits 
per  Hz.  Specifically,  a  9.6-kbps  channel  may  require  on  the  order  of  20  kHz  of 
bandwidth  and  a  10-Mbps  channel  on  the  order  of  18  MHz. 

9.3.4  Fiber  Optic  Cable 

Optical  fibers  are  usually  classified  by  the  type  of  refractive  index  profile  of  their  many 
layers  of  glass.  Commonly  used  profile  types  are  single-mode  and  multimode.  In  most  types  of 
fiber  the  outside  cladding  diameter  is  approximately  125  microns.  The  core  diameter  for  single 
mode  fiber  is  typically  8  microns,  whereas  multimode  cores  range  from  30  to  100  microns  in 
diameter.  Lasers  are  used  for  long-distance  communication  and  light-emitting  diodes  for  cost 
sensitive  applications  that  are  limited  in  speed  (230  Mbps)  and  distance  (1  kilometer).  [Ref. 
Cemy  1991,  p.  167] 

9.3.5  Interface  Standards  to  Communications  Media 

A  variety  of  standards  that  enable  equipment  to  interface  to  communication  media  have  been 
developed.  Interoperability  parameters  for  two  of  these  (RS-449  and  RS-423A)  are  defined  in 
detail  in  Appendix  A 

Connector  standards  have  been  available  for  more  than  30  years.  Many  were  developed 
and  extended  by  the  Electronic  Industries  Association  (EIA).  The  following  are  the  most  common 
connector  standards  [Ref.  Stallings  1991,  pp.  134-142]: 

•  RS-232C,n  a  25-pin  connector  with  a  specific  arrangement  of  leads.  It  utilizes  a 
signalling  convention  based  on  common  ground,  where  a  voltage  more  negative  than 


38  RS232C  is  (be  third  edition  of  RS-232,  developed  by  EIA  in  1969.  The  fourth  edition,  RS-232D  (1987)  differs 
in  that  it  specifies  only  a  cable  connector  and  has  three  additional  circuits  for  test  operations. 
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-3V  is  interpreted  as  binary  1  and  a  voltage  more  positive  than  +3V  is  interpreted  as 
binary  0.  The  interface  is  rated  at  a  signal  rate  of  less  than  20  kbps  and  a  distance  of 
less  than  IS  meters  (m). 

•  RS-422-A  specifies  balanced  transmission  and  achieves  a  rate  performance  of 
100  kbps  at  1,200  m  to  10  Mbps  at  12  m. 

•  RS-423-A  specifies  unbalanced  transmission  and  achieves  a  rate  performance  of 
3  kbps  at  1,000  m  to  300  kbps  at  10  m. 

•  RS-449/  (37-pin  connector)  defines  the  mechanical,  functional,  and  procedural  aspects 
of  the  new  interface  and  refers  to  RS-422-A  and  RS-423-A  for  defining  electrical 
characteristics.  Functionally,  RS-449  retains  all  of  the  interchange  circuits  of  RS-232- 
C,  with  the  exception  of  protective  grounds,  and  adds  10  new  circuits.  RS-449  has 
not  received  the  popular  adoption  accorded  to  RS-232,  partly  due  to  the  fact  that  its  37- 
pin  interface  requires  more  of  a  product’s  surface  area  than  die  23-pin  RS-232. 

•  EIA-530  was  introduced  in  1987  using  the  same  25-pin  connector  as  for  RS-232. 
EIA-530  is  intended  to  operate  at  rates  from  20  kbps  to  2  Mbps.  Unlike  RS-232  and 
like  RS-449,  EIA-520  refers  to  RS-422-A  and  RS-423-A  for  defining  electrical 
characteristics. 

9.4  Data  Link  Layer  Standards 

9.4.1  Data  Link  Requirements 

In  the  OSI  model,  the  Data  Link  Layer  provides  the  functional  and  procedural  means  to 
establish,  maintain,  and  release  data-link  connections  on  behalf  of  network  entities.  The  Data  Link 
Layer  attempts  to  make  die  Physical  Layer  reliable  by  providing  error  detection  and  control.39  Data 
link  control  protocols  are  designed  to  deal  with  a  variety  of  physical  link  characteristics  and  modes 
of  operation  including  [Stallings  199 3,  p.37;  Stallings  1987,  pp.  70-83]: 

•  Point-to-point  and  multi-point  link 

•  Long  and  short  distance  connections 

•  Half-duplex  (two-way  alternate)  and  full-duplex  (two-way  simultaneous)  operation 

•  Primary-secondary  (e.g.,  host-terminal)  and  peer  (e.g.,  computer-to-computer) 
interactions. 

In  addition,  data  link  layer  protocols  are  intended  to  satisfy  the  objectives  of  code  independence, 
adaptability,  high  efficiency,  and  high  reliability. 

There  are  two  modes  of  data  link  service:  character-oriented  service  (basic  mode)  and  bit- 
oriented  service.  Standards  for  basic  modes  include  ISO  1 133,  ISO  1 177,  ISO  1745,  ISO  2111, 
ISO  2628,  and  ISO  2629  (see  Section  m.B  of  Appendix  D).  Bit-oriented  services  are  provided  by 
high-level  data  link  control  (HDLC)  and  integrated  services  digital  network  (ISDN);  these  are  the 
most  commonly  used  and  are  described  in  detail  below. 

Data  link  requirements  can  be  met  by  bit-oriented  synchronous  data  link  protocols.  A 
number  of  very  similar  bit-oriented  protocols  have  achieved  widespread  use  [Ref. 
Stallings  1991,  p.  171]: 

•  HDLC,  developed  by  ISO  and  widely  used  for  point-to-point  and  multidrop 
configurations 


39  See  Section  922  cm  military  requirements  for  a  comment  on  error  correction  services. 
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•  Advanced  data  communication  control  procedures  (ADCCP)  developed  by  ANSI 
(ANSI  X3.66)  and  adopted  in  the  United  States  by  NIST  for  use  on  federal 
procurements  with  very  minor  modifications40 

•  Logical  Link  Control  (LLC),  defined  for  LANs 

•  Link  Access  Procedure,  Balanced  (LAPB),  used  by  ITU-TS  as  part  of  its  X.2S 
packet-switched  network  standard 

•  link  Access  Procedure,  D-Channel  (LAPD),  used  in  mj-TS’s  ISDN 

•  Synchronous  Data  Link  Control  (SDLC),  developed  and  used  by  IBM,  is  not  a 
standard  but  is  in  widespread  use. 

Small  differences  exist  between  HDLC  and  ADCCP.  LAPB  is  a  subset  of  HDLC.  SDLC  is  also  a 
subset  of  HDLC,  but  includes  several  additional  features.  A  comparison  of  interoperability 
parameters  for  three  military  protocols  derived  from  HDLC  and  ADCCP  with  the  ISO  standards  is 
provided  in  Section  S  of  Appendix  C. 

9.4.2  HDLC 

Hie  following  are  the  key  HDLC  standards  (see  Section  EC  of  Appendix  D): 

•  ISO  3309,  HDLC  -  Frame  Structure,  Edition  4  (1991) 

•  ISO  4335,  HDLC  -  Elements  of  Procedures,  Edition  4  (1991) 

•  ISO  7776,  HDLC  -  Description  of  the  X.25  LAPB-Compatible  DTE  Data  Link 
Procedures 

•  ISO  7809,  HDLC  -  Consolidation  of  Classes  of  Procedures,  Edition  2  (1991) 

•  ISO  8471,  HDLC  Balanced  Classes  of  Procedures  -  Data  Link  Layer  Address 
Resolution/Negotiation  in  Switched  Environments 

•  ISO  8885,  HDLC  -  General  Purpose  XID  Frame  Information  Field  Content  and 
Format,  Edition  2  (1991). 

HDLC  uses  synchronous  transmission.  All  transmissions  are  in  frames,  and  a  single  frame 
format  suffices  for  all  types  of  data  and  control  exchanges.  The  frame  has  the  following  fields 
[Ref.  Stallings  1993,  p.  58;  Stallings  1991,  p.  173]: 

•  Flag  (8  bits) — appears  at  the  beginning  and  end  of  each  frame  and  is  used  for 
synchronization 

•  Address  (one  or  more  octets) — indicates  the  secondary  station  for  a  transmission;  it  if 
needed  in  the  case  of  a  multidrop  line,  where  a  primary  may  send  data  to  one  of  a 
number  of  secondaries  and  one  of  a  number  of  secondaries  may  send  data  to  the 
primary 

•  Control  (8  or  16  bits) — identifies  the  purpose  and  functions  of  the  frame  (see  below) 

•  Information  (variable  octets) — contains  the  user  data  to  be  transmitted 

•  Frame  Check  Sequence  (16  or  32  bits) — used  in  the  mode  of  a  cyclic  redundancy 
check  for  error  detection. 

HDLC  defines  three  types  of  frames,  each  with  a  different  control-field  format 
Information  frames  (I-frames)  carry  the  user  data  to  be  transmitted  for  the  station.  Additionally, 
information  frames  contain  control  information  for  flow  control  and  error  control.  The  supervisory 
frames  (S-frames)  provide  another  means  of  exercising  flow  control  and  error  control. 
Unnumbered  frames  (U-fraraes)  provide  supplemental  link-control  functions.  Use  of  these  frame 

40  Two  examples  of  military  protocols  derived  from  ADCCP  are  given  in  Appendix  C  (Sections  3  and  4). 
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types  and  some  of  the  14  HDLC  options  are  illustrated  in  Sections  3-S  of  Appendix  C.  [Ref. 
Stallings  1993,  p.  59] 

9.4.3  Multilink  Procedure 

HDLC  and  most  other  link  control  protocols  are  designed  to  operate  over  a  single  physical 
circuit  between  two  systems.  In  some  cases,  multiple  parallel  physical  circuits  exist  between  a 
single  pair  of  systems.  ISO  has  defined  a  multilink  procedure  (MLP)  to  operate  over  multiple  lines 
to  achieve  greater  throughput  and  reliability  (ISO  7478,  Multilink  Procedures).  Over  each  line,  a 
single  link  procedure,  such  as  HDLC,  is  used.  The  MLP  operates  above  the  single  link  procedure, 
and  may  be  thought  of  as  an  upper  sublayer  of  the  data  link  layer.  [Ref.  Stallings  1993,  p.  64] 

When  a  Layer  3  protocol  data  unit  (PDU)  is  presented  to  the  MLP  for  transmission,  any 
available  link  may  be  chosen.  Indeed,  the  MLP  may  assign  successive  PDUs  to  different  links  to 
satisfy  throughput  or  availability  constraints.  [Ref.  Stallings  1987,  p.  92] 

9.4.4  Logical  Link  Control  (LLC) 

LLC  is  the  data  link  standard  defined  for  local  area  networks  (ISO  8802-2,  Local  Area 
Networks ,  Part  2:  Logical  Link  Control).  A  revision  of  the  1989  edition  of  this  standard  is  in 
progress  and  has  reached  DIS  status. 

LLC  makes  use  of  only  the  asynchronous  balanced  mode  of  operation  of  HDLC.  The  key 
difference  between  LLC  and  the  traditional  standards,  such  as  HDLC,  is  that  LLC  is  designed  to 
operate  over  a  peer  multi-point  link  (termed  “multiplexing”).  In  this  case,  there  are  multiple 
devices  attached  to  a  transmission  medium,  all  of  which  are  capable  of  initiating  transmission;  there 
is  no  unique  primary  on  the  link.  To  account  for  this,  each  transmitted  data  unit  includes  both  the 
sending  and  receiving  address,  rather  than  just  the  address  of  a  secondary.  [Ref. 
Stallings  1987,  p.  97] 

The  LLC  standard  specifies  three  types  of  services  that  may  be  offered  to  the  network  layer 
[Ref.  Stallings  1993,  pp.  321-324]: 

•  Type- 1 — unacknowledged  connectionless  service,  which  has  the  same  characteristics 
as  any  OSI  connectionless-mode  service,  provides  no  flow  control  or  error  control, 
and  (kies  not  guarantee  the  delivery  of  data  in  the  order  in  which  they  were  sent 

•  Type-2 — connection-oriented  service,  which  is  similar  to  the  connection-mode 
network  service 

•  Type- 3 — acknowledged  connectionless  service,  which  provides  a  mechanism  by 
which  a  user  can  send  a  unit  of  data  and  receive  an  acknowledgment  that  the  data  were 
delivered,  without  the  necessity  of  setting  up  a  connection. 

A  system  can  support  more  than  one  of  these  types  in  the  following  combinations:  Type  1  alone. 
Types  1  and  2,  Types  1  and  3,  and  all  three  types.  (Type  1  is  mandatory.) 

9.4.5  LAPB 

LAPB  is  designed  for  use  on  X.25,  which,  like  LLC,  is  a  subset  of  the  asynchronous 
balanced  mode  of  HDLC.  LAPB  is  restricted  to  Options  2, 8,  and  10  of  the  14  options  permitted 
by  HDLC.  LAPB  is  the  most  commonly  specified  form  of  HDLC  for  wide  area  networks 
(WANs).  It  is  used  for  point-to-point  link  between  a  user  system  (termed  data  terminal  equipment 
or  DTE)  and  a  packet  switched  network  node  (an  example  of  a  data  circuit-terminating  equipment 
or  DCE).  When  multiple  links  exist  between  DTE  and  DCE,  each  link  is  governed  by  LAPB.  It  is 
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also  used  in  LANs,  where  packets  flow  in  only  one  direction  at  a  time.  [Ref.  Stallings  1987, 
p.  113;  Stallings  1993,  p.  63] 

9.4.6  LAPD 

LAPD  is  a  data  link  standard  (ITU-TS  1.441)  developed  as  part  of  the  ISDN 
standardization  effort  It  specifies  a  link  access  protocol  to  be  used  over  a  logical  channel,  known 
as  the  D-channel,  that  is  part  of  a  time-multiplexed  link  between  a  network  subscriber  and  the 
ISDN  central  office.  LAPD  is  a  variant  of  HDLC,  based  on  LAPB.  [Ref.  Stallings  1987,  p.  97] 

LAPD  provides  two  forms  of  service  to  users:  unacknowledged  information  transfer 
service  and  acknowledged  information  transfer  service.  The  unacknowledged  information  transfer 
service  simply  provides  for  the  transfer  of  frames  containing  user  data  with  no  acknowledgment, 
no  guarantee  of  data  delivery,  no  notice  if  the  delivery  attempt  fails,  no  flow  control,  and  no  error 
control.  This  service  supports  both  point-to-point  (deliver  to  one  user)  and  broadcast  (deliver  to  a 
number  of  users),  allows  for  fast  data  transfer,  and  is  useful  for  management  procedures  such  as 
alarm  messages  and  messages  that  need  to  be  broadcast  to  multiple  users.  The  acknowledged 
information  transfer  service  is  the  more  common  one  and  is  similar  to  the  service  offered  by  LAPB 
and  HDLC.  With  acknowledged  information  transfer  service,  a  logical  connection  is  established 
between  two  LAPD  users  prior  to  the  exchange  of  data.  [Ref.  Stallings  1993,  p.  228] 

LAPD  has  to  deal  with  two  levels  of  multiplexing.  First,  at  a  subscriber  site,  there  may  be 
multiple  user  devices  sharing  the  same  physical  interface.  Second,  within  each  user  device,  there 
may  be  multiple  types  of  traffic,  especially  packet-switched  data  and  control  signalling.  To 
accommodate  these  levels  of  multiplexing,  LAPD  employs  a  two-part  address,  consisting  of  a 
terminal  endpoint  identifier  (TEI)  and  a  service  access  point  identifier  (SAPI).  Typically,  each  user 
device  is  given  a  unique  TEL  It  is  also  possible  for  a  single  device  to  be  assigned  more  than  one 
TEL  This  might  be  the  case  for  a  terminal  concentrator.  The  SAPI  identifies  traffic  type.  [Ref. 
Stallings  1987,  p.  97] 

9.5  LAN  Technologies 

There  are  many  ways  to  view  LAN  technologies  and  to  categorize  LANs.  One  of  the  more 
common  ways  is  to  group  them  by  transmission  and  switching  technologies.  The  categories  are 
[Ref.  Slone  1991,  pp.  80-82]: 

*  Baseband  LANs  were  the  first  to  be  used  on  a  large  scale  basis.  Their  distinctive 
feature  is  their  use  of  a  single  transmission  medium  and  a  single  transmission  channel. 
Because  baseband  LANs  were  the  first  to  be  widely  used,  support  equipment  such  as 
bridges,  gateways,  servers,  and  test  equipments  are  readily  available. 

*  Broadband  LANs  employ  many  of  the  technologies  used  by  the  cable  television 
industry.  For  example,  broadband  LANs  and  cable  television  generally  use  the  same 
coaxial  cable,  amplifiers,  splitters  xmplers,  and  taps.  To  adapt  this  technology  for 
data  transmission,  radio  frequency »  oderns  are  used  to  convert  the  digital  data  signals 
into  analog  signals.  These  signals  iit  on  one  of  the  many  cable  channels  in  the  same 
way  that  different  television  channels  are  carried  on  commercial  cable  systems. 

*  Switched-Based  LANs  are  of  different  types,  including  private  branch  exchanges 
(PBXs)  and  telephone  companies’  central  offices.  These  LANs  are  capable  of 
providing  both  circuit  and  packet  switching  on  a  single  network.  Circuit  switching  is 
more  suitable  for  calls  that  transmit  large  amounts  of  data  for  a  relatively  long  period  of 
time,  whereas  low-volume,  interactive  traffic  is  mote  efficiently  served  by  packet 
switching.  Neither  baseband  or  broadband  LANs  are  well  suited  for  circuit  switching. 
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•  Hybrid  LANs.  Several  other  types  of  LANs  are  available,  but  they  ate  primarily 
hybrids  or  adaptations  of  the  types  discussed.  Another  hybrid  is  a  combined  voice  and 
data  version  of  Fiber  Distributed  Data  Interface  (FDDI),  a  high-speed  fiber  network 
.  standard  being  developed  by  ANSI  (see  Section  9.5.7).  This  network  is 
technologically  a  baseband  system  because  all  devices  share  a  single  digital  channel  on 
a  single  medium. 

9.5.1  LAN  Standards 

The  IEEE  802  working  groups  were  chartered  to  create  standards  by  which  devices  could 
communicate  over  LANs.  The  working  groups  have  created  a  flexible  framework  for  LANs 
spanning  the  lower  two  OSI  levels,  including  network  management  and  internetworking  of  these 
layers.  Table  15  depicts  the  model  used  for  LAN  standards. 


Table  15.  Modal  for  LAN  Standards 


OSI  Layer 

LAN  Model  Layer  | 

Data  Link  Layer 

ItSHliiSHI 

Physical  Layer 

Li  ih  I 3 1R.7TT1  JTTvT?— 

Source:  [Stagings  1993,  p.  319], 


The  LAN  functions  associated  with  the  OSI  Data  Link  Layer  include  [Ref. 
Stallings  1993,  p.  320]: 

•  Providing  one  or  more  service-access  points  (SAPs) 

•  On  transmission,  assembling  data  into  a  frame  with  address  and  cyclic  redundancy 
check  (CRC)  fields 

•  On  reception,  disassembling  the  frame  and  performing  address  recognition  and  CRC 
validation 

•  Governing  access  to  the  LAN  transmission  medium. 

The  first  function  and  related  functions  are  grouped  into  the  logical  link  control  (LLC)  sublayer. 
The  last  three  functions  are  treated  as  a  separate  layer,  called  medium-access  control  (MAC) 
sublayer.  LAN  standards  include  the  MAC-to-physical  layer  interface  and  the  MAC-to-LLC 
interface. 

The  physical  layer  includes  such  functions  as  encoding/decoding  of  signals,  preamble 
generation/removal  (for  synchronization),  and  bit  transmission/reception.  In  addition,  the  physical 
layer  of  the  LAN  model  includes  a  specification  of  the  transmission  medium.  Generally,  this  is 
considered  below  the  lowest  layer  of  the  OSI  model.  However,  the  choice  of  transmission 
medium  is  critical  in  LAN  design,  and  so  a  specification  of  the  medium  is  included.  [Ref. 
Stallings  1993,  p.  319] 

Table  16  identifies  the  current  LAN  standards.  It  shows  that  second  editions  of 
ISO  8802-1  and  ISO  8802-2  are  in  progress  and  have  reached  DIS  stage.  These  will  update  the 
original  standards  adopted  in  1987  and  revised  in  1989.  Edition  3  of  ISO/IEC  8802-3  was 
approved  and  distributed  in  1992.  At  that  time,  the  title  of  ISO  8802  was  changed  from  Local  Area 
Networks  to  Local  Area  Networks  and  Metropolitan  Area  Networks  (MANs). 
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Table  16.  LAN  Standard* 


JEC  647 
EC/TR907 
ISO  8802-1 
DIS  8802-1 .2 
ISO  8802-2 
DIS  8802-2.2 
DAMl 
DAM  2 
DAM  3 
DAM  4 
PDAM5 
ISO/IEC  8802-3 

ISO/IEC  8802-4 
ISO/IEC  8802-5 

DIS  8802-6 
ISO/IEC  8802-7 
DIS  8802-9 
CD  8802-51 
ISO/IEC  8881 
ISO  9314-1 
TR  9578 
DIS  10038 

PDAM1 
DAM  2 

ISO/IEC  10039 


Charadaristic*  of  LANs.  1988 
Local  Arsa  Networks  CSMA/CD 10  Mbps  Baseband  Planning  and  InstakaUon  Quids 
LANs,  Part  1:  General  Introduction,  1989 

LANs  and  MANs,  Parti:  General  Introduction  with  System  Load  Protocol 

LANs,  Part  2:  Logical  Link  Control,  1989 

LANs  and  MANs,  Part  2:  Logical  Link  Control,  Edition  2  (draft) 

Flow  Control  Techniques  for  Bridged  LANs 

Type  3  Operation  -  Acknowledge  Connectionless  Service 

PICS  Prolorma 

Editorial  Changes  and  Technical  Corrections 
Bridged  LAN  Source  Routing  Operations  by  End  Systems 

LANs  and  MANs,  Part  3:  Carrier  Sense  Multiple  Access  with  Coition  Detection  (CSMA/CD) 

•  Access  Method  and  Physical  Layer  Specifications,  Edition  3, 1993 

LANs,  Part  4:  Token-Passing  Bus  Access  Method  and  Physical  Layer  Specifications,  1990 

LANs  and  MANs,  Part  5:  Token  Ring  Access  Method  and  Physical  Layer  Specifications, 

1992 

LANs.  Part  6:  Distributed  Queue  Dual  Bus  (DQDB)  Media  Access  Control  (MAC) 

LANs,  Part  7:  Slotted  Ring  Access  Method  and  Physical  Layer  Specification,  1991 

LANs,  Part  9:  Integrated  Voice  and  Data  (IVD)  LAN 

LANs,  Part  51:  MAC  Sublayer  Conformance  Test  Purposes 

Use  of  toe  X.25  Packet  Level  Protocol  (PLP)  in  Local  Area  Networks 

Ffeer  Distributed  Data  Interface  (FDDI),  Part  1:  Physical  Layer  Protocol  (PHY) 

Communication  Interface  Connectors  Used  in  LANs 

MAC  Sublayer  Interconnection  (MAC  Bridging) 

Specification  of  Management  Information  for  CMIP 
Source  Routing  Supplement 
MAC  Service  Definition 


ISO/IEC  TR 10178  Structure  and  Coding  of  Link  Service  Access  Point  Addresses  in  LANs 
ISO/IEC  TR  10738  Recommended  Practice  for  Use  of  Unshielded  Twisted  Pair  Cable  (UTP)  for  Token  Ring  Data 
Transmission  at  4  Mbps 


9.5.2  CSMA/CD  LANs 

In  carrier  sense  multiple  access  with  collision  detection  (CSMA/CD;  ISO/IEC  8802-3),  a 
station  wishing  to  transmit  fust  listens  to  the  medium  to  determine  whether  another  transmission  is 
in  progress  (carrier  sense).  If  the  medium  is  idle,  the  station  may  transmit  It  could  happen  that 
two  or  more  stations  attempt  to  transmit  at  about  the  same  time;  if  this  occurs,  there  will  be  a 
collision — the  data  from  both  transmissions  will  be  garbled  and  not  received  successfully. 
CSMA/CD  specifies  what  a  station  should  do  if  the  medium  is  found  to  be  busy  and  what  to  do  if  a 
collision  occurs.  [Ref.  Stallings  1993,  p.  327] 

The  following  are  the  medium-dependent  physical  layer  standards  incorporated  into  the 
CSMA/CD  (sometimes  called  Ethernet)  standard  [Ref.  Stallings  1993,  pp.  330-356]: 

•  10BASE541 — 10-Mbps  baseband  system  using  50-ohm  coaxial  cable  (10-mm 
diameter)  with  a  maximum  segment  length  of  500  m;  its  length  can  be  extended  to 
2,500  m  by  use  of  repeaters 

•  10BASE2 — 10-Mbps  baseband  system  using  a  smaller  (5-ram  diameter)  50-ohm 
coaxial  cable  with  a  maximum  segment  length  of  185  m;  its  length  can  be  extended  to 


4 11  The  structured  name  specifies  baseband  (BASE)  or  broadband  (BROAD)  transmission;  bit  rate  in  Mbps  (e.g.,  10 
in  10BASE5  denotes  10  Mbps),  and  approximate  maximum  segment  length  in  hundreds  of  meters  (e.g  ,  5  in 
10BASES  denotes  500  m). 
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925  m  by  use  of  repeaters  (10BASE2  is  a  lower  cost  option  than  10BASE5  applicable 
for  personal  computers) 

•  1BASE5 — 1-Mbps  baseband  system  using  unshielded  twisted-pair  cable  (ordinary 
telephone  wire,  0.4-0.6-mm  diameter)  with  a  maximum  segment  length  of  500  m;  its 
length  can  be  extended  to  2,500  m  by  use  of  repeaters  (1BASE5  is  an  even  lower  cost 
option  than  10BASE5  that  uses  standard  telephone  wiring  typical  of  many  building 
installations) 

•  10BASET — 10-Mbps  baseband  system  using  twisted-pair  cable  with  a  maximum 
segment  length  of  100  m;  its  length  can  be  extended  to  500  m  by  use  of  repeaters  (this 
variant  of  1BASE5  trades  increased  bandwidth  for  decreased  maximum  segment 
length) 

•  10BROAD36 — 10-Mbps  broadband  system  using  75-ohm  coaxial  cable  (standard  for 
cable  television;  0.4-1.0-mm  diameter)  with  a  maximum  segment  length  of  3,600  m 
(two  1,800-m  segments  from  a  head-end). 

•  100BASET — 100-Mbps  baseband  system  using  fiber  or  twisted-pair  cable  (this  is  still 
under  development). 

•  lOOVG-AnyLAN — expected  to  provide  a  100  Mbps  migration  path  from  10-Mbps 
CSMA/CD  and  16- Mbps  token  ring  networks;  combines  100-Mbps  transmission  with 
a  MAC  layer  that  operates  over  Category  3, 4  or  5  unshielded  twisted-pair,  shielded 
twisted-pair,  and  optical  fiber. 

9.5.3  Token  Bus  LANs 

For  a  token  bus  LAN  (ISO/IEC  8802-4),  the  stations  on  the  bus  or  tree  form  a  logical  ring, 
in  which  the  stations  are  assigned  logical  positions  in  an  ordered  sequence  and  for  which  the  last 
member  of  the  sequence  is  followed  by  the  first  Each  station  knows  the  identity  of  the  station 
preceding  and  following  it  The  physical  ordering  of  the  stations  on  the  bus  is  irrelevant  to  and 
independent  of  the  logical  ordering.  A  control  frame,  known  as  the  token,  regulates  the  right  of 
access.  The  token  contains  a  destination  address.  The  station  possessing  the  token  is  granted 
control  of  the  medium  for  a  specified  time.  The  station  may  transmit  one  or  more  frames  and  may 
poll  stations  and  receive  responses.  When  the  station  is  finished  of  time  has  expired,  it  passes  the 
token  to  the  next  station  in  logical  sequence.  This  station  now  has  permission  to  transmit  Hence, 
normal  operation  consists  of  alternating  data-transfer  and  token-transfer  phases.  In  addition,  non- 
token-using  stations  are  allowed  on  the  bus;  they  can  only  respond  to  polls  or  request  for 
acknowledgment  [Ref.  Stallings  1993,  p.  339] 

The  following  are  the  medium-dependent  physical  layer  standards  incorporated  into  this 
standard  [Ref.  Stallings  1993,  pp.  347-349]: 

•  Phase-continuous  carrier  band —  1  -Mbps  phase-continuous  carrier  band,  using  a  form 
of  frequency-shift  keying  (FSK),  in  which  the  transition  between  signalling 
frequencies  is  accomplished  by  a  continuous  change  of  frequency,  as  opposed  to  the 
discontinuous  replacement  of  one  frequency  by  another,  resulting  in  a  tighter 
bandwidth  and  improved  transmission  and  reception  efficiency.  Digital  data  are 
transmitted  using  Manchester  encoding  and  then  passed  through  a  modem  at 
6.25  MHz  (high)  and  3.75  MHz  (low). 

•  Phase-coherent  carrier  band — the  phase-coherent  FSK  carrier  band,  using  a  data  rate 
of  5  and  10  Mbps  (phase  coherent  means  that  the  two  signalling  frequencies  are 
integrally  related  to  the  data  rate,  ensuring  that  the  zero  crossing  points  are  in  phase  at 
the  beginning  and  end  of  each  bit  time). 
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•  Broadband — the  broadband  specification  allowing  for  data  rates  of  1,5,  and  10Mbps, 
with  bandwidths  of  1.5, 6,  and  12  MHz,  respectively.  The  standard  recommends  the 
use  of  a  single-cable  system  with  a  head-end  frequency  translator.  Dual  cable  is  also 
permitted. 

•  Optical  fiber — allowing  three  data  rates:  5,  10,  and  20  Mbps.  In  keeping  with 
standard  practice  for  optical  fiber  systems,  the  bandwidth  and  carrier  are  specified  in 
terms  of  wavelength  (nm  or  nanometers).  For  all  three  data  rates,  the  bandwidth  is 
270  nm,  and  the  center  wavelength  is  between  800  and  910  nm. 

9.5.4  Men  Ring  LANs 

Intended  for  use  in  commercial,  military,  and  light  industrial  environment,  a  token  ring  is 
composed  of  a  number  of  stations  serially  connected  by  a  medium.  As  for  token  bus,  the  media 
access  control  protocol  (ISO/IEC  8802-5)  is  based  on  use  of  a  frame  called  a  token.  The  token 
circulates  on  the  ring  when  all  stations  are  idle.  A  station  wishing  to  transmit  must  wait  until  it 
detects  a  token  passing  by.  It  then  seizes  the  token  (by  changing  one  bit  in  the  token  and  changing 
it  to  a  start-of-frame  sequence  for  a  data  frame)  and  appends  the  rest  of  a  data  frame.  When  a 
station  seizes  the  token  and  begins  to  transmit  a  data  frame,  there  is  no  token  on  the  ring,  so  other 
stations  wishing  to  transmit  must  wait  The  frame  on  the  ring  will  make  a  round  trip  and  be 
absorbed  by  the  transmitting  station,  which  will  then  insert  a  new  token  on  the  ring.  Once  the  new 
token  has  been  inserted  on  the  ring,  the  next  station  downstream  with  data  to  send  will  be  able  to 
seize  the  token  and  transmit  [Ref.  Stallings  1993,  p.  350-351] 

The  standard  specifies  the  use  of  shielded  twisted-pair  wire  with  data  rates  of  4  and 
16  Mbps.  Differential  Manchester  encoding  is  used.  The  unshielded  twisted-pair  version  operates 
at  4  Mbps.  [Ref.  Stallings  1993,  p.  356]  A  new  standard  for  this  is  ISO/IEC  TR  10738,  Token 
Ring  Access  Method  and  Physical  Layer  Specifications  -  Recommended  Practice  for  Use  of 
Unshielded  Twisted  Pair  Cable  (UTP)for  Token  Ring  Data  Transmission  at  4  Mbit/s,  1993. 

9.5.5  Metropolitan  Area  Networks  (MANs) 

The  MAN  standard  (DIS  8802-6;  ANSI/IEEE  802.6)  was  designed  to  occupy  a  middle 
ground  between  the  LAN  and  wide  area  networks  (WANs).  The  standard  is  referred  to  as  the 
distributed-queue  dual-bus  (DQDB)  subnetwork  standard,  since  medium-access  control  is  based 
on  the  maintenance  of  distributed  queues.  [Ref.  Stallings  1993,  pp.  389-390, 433]  A  MAN  has 
two  separate  unidirectional  buses,  both  of  which  carry  data  at  the  same  time.  Reconfiguration  is 
possible  when  a  link  breaks  (and  with  looped  topology,  full  connectivity  is  maintained). 

The  medium  access  control  protocol  is  based  on  time  division  multiple  access.  It  uses 
reservations,  where  the  time  is  divided  into  continuous,  discrete  time  segments  (frames)  of  125  |is. 
Each  frame  is  subdivided  into  a  number  of  53-octet  cells,  depending  on  the  speed  of  the  channel. 
Because  of  compatibility  of  cell  size,  MANs  can  be  readily  integrated  with  asynchronous-transfer¬ 
mode  (ATM)-based  broadband  ISDN  and  other  networks  based  on  ATM  (see  Section  9.6.3). 

The  medium-access-control  technique  is  based  on  the  maintenance  of  distributed  queues,  in 
which  each  node  maintains  queues  of  outstanding  requests  that  determine  access  to  the  MAN 
medium.  This  DQDB  scheme  supports  both  packet  mode  and  isochronous42  mode  data  transfer. 


42  ISO  2382  defines  isochronous  transmission  as  a  data  transmission  process  in  which  there  is  always  an  integral 
number  of  unit  intervals  between  any  two  significant  events. 
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The  transmission  systems  currently  specified  are  [Ref.  Stallings  1993,  p.  407-408]: 

•  ANSI  SONET  STS-3c  OTU-TS  Synchronous  Digital  Hierarchy^— transmits  data  at 
1SS.S2  Mbps  and  above  over  a  single-mode  fiber  (see  Section  9.6.1) 

•  ITU-TS  G.703 — transmits  data  at  34.368  Mbps  and  139.264  Mbps  over  a  metallic 
medium 

•  ANSI  DS3 — transmits  data  at  44.736  Mbps  over  75-ohm  coaxial  or  fiber  media  and 
provides  a  frame  size  of  595  octets  and  a  frame  duration  of  106.4  ps;  it  is  a  commonly 
used  transmission  system  for  North  America. 

9.5.6  Wireless  LANs 

IEEE  802.1 1  is  working  on  a  wireless  LAN  standard,  with  a  draft  expected  early  in  1994. 

9.5.7  FDDI  LANs 

9.5. 7.1  FDDI  LAN  Standards 

The  Fiber  Distributed  Data  Interface  (FDDI)  standards  are  the  following: 

•  ISO  9314-1,  FDDI,  Part  1:  Physical  Layer  Protocol  [ANSI  X3.148-1988] 

•  ISO  9314-2,  FDDI,  Part  2:  Media  Access  Control  (MAC)  [ANSI  X3. 139-1986] 

•  ISO/EEC  9314-3,  FDDI,  Part  3:  Physical  Layer  Medium  Dependent  (PMD)  [ANSI 
X3. 166- 1990] 

•  ISOdEC  9314-4,  FDDI,  Part  4:  Single-Mode  Fiber/Physical  Layer  Medium  Dependent 
[ANSI  X3. 184-1993] 

•  DIS  9314-5,  FDDI,  Part  5:  Hybrid  Ring  Control  (FDDI-II)  [ANSI  X3.186-199X] 

•  CD  9314-6,  FDDI,  Part  6:  Station  Management  (SMT)  Standard  [ANSI  X3.229- 
199x]. 

The  FDDI  is  a  set  of  standards  developed  by  ANSI  X3T9.5.  Basic  FDDI  supports  a 
packet-mode  data  transfer  service.  The  timed  token  access  method,  used  to  share  the  medium 
among  stations  in  this  100-Mbps  LAN,  differs  from  the  traditional  token  ring  method 
(ISCVIEC  8802-5)  in  that  the  time  for  the  token  to  walk  around  the  ring  is  accurately  measured  by 
each  station  and  used  to  determine  the  usability  of  the  token.  Two  differences  from  the  token  ring 
LAN  are  as  follows  [Ref.  Stallings  1993,  p.  367]: 

•  In  FDDI,  a  station  waiting  for  a  token  seizes  the  token  by  aborting  (failing  to  repeat) 
die  token  transmission  as  soon  as  the  token  frame  is  recognized  (rather  than  flipping  a 
bit  in  the  token  to  the  start  of  a  data  frame,  which  is  less  efficient).  After  the  captured 
token  is  completely  received,  the  station  begins  transmitting  (Hie  or  more  data  frames. 

•  In  FDDI,  the  station  that  has  been  transmitting  data  frames  releases  a  new  token  as 
soon  as  it  completes  data-frame  transmission  (a  technique  known  as  early  frame 
release),  which  is  more  efficient  than  waiting  for  its  frame  to  return  as  in  normal  token 
ring  operation. 

The  FDDI  standard  encompasses  both  the  MAC  and  physical  layers.  FDDI  defines  two 
types  of  traffic:  synchronous  and  asynchronous.  Each  station  is  allocated  a  portion  of  the  total 
capacity  (this  portion  may  be  zero);  the  frames  that  it  transmits  during  this  time  are  referred  to  as 
synchronous  frames.  Any  capacity  that  is  not  allocated  or  that  is  allocated  but  not  used  is  available 
for  the  transmission  of  additional  frames,  referred  to  as  asynchronous  frames.  [Ref. 
Stallings  1993,  pp.  364,  369] 

The  FDDI  standard  specifies  an  optical-fiber  ring  with  a  data  rate  of  100  Mbps,  using 
NRZI-4B/5B  encoding  scheme.  The  wavelength  specified  for  data  transmission  is  1,300  nm.  The 
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dimensions  of  the  fiber  cable  are  specified  in  terms  of  the  diameter  of  the  cote  fiber  and  the  outer 
diameter  of  the  cladding  layer  that  surrounds  the  core.  The  combination  specified  in  the  standard  is 
62.S/12S  pm  (micro-meter).  The  standard  lists  as  alternatives  50/125, 82/125,  and  100/140  pm. 
[Ref.  Stallings  1993,  p.  380] 

The  SMT  standard  (CD  9314-6)  provides  the  control  necessary  at  the  station  (node)  level  to 
manage  the  processes  underway  in  the  various  FDDI  layers  such  that  a  station  (node)  may  work 
cooperatively  as  a  part  of  an  FDDI  network.  It  will  provide  such  services  as  connection 
management,  station  insertion  and  removal,  station  initialization,  configuration  management,  fault 
isolation  and  recovery,  communications  protocol  for  external  authority,  scheduling  policies,  and 
collection  of  statistics.  [Ref.  X3  1992d] 

9.5. 7. 2  FDDI-II  LAN  Standards 

FDDI-II  is  an  upward-compatible  extension  to  FDDI  that  adds  the  ability  to  support  circuit- 
switched  (isochronous)  traffic,  in  addition  to  the  packet-mode  traffic  supported  by  basic  FDDI. 
With  FDDI-II,  it  is  possible  to  set  up  and  maintain  a  constant-data-rate  connection  between  two 
stations  using  a  regularly  repeating  (125-ps-long)  time  slots  in  the  frame.  At  100  Mbps,  each  cycle 
permits  12,500  bits  to  be  transmitted.  This  capability  is  divided  into  sixteen  96-octet  channels, 
each  with  a  capacity  of  6.144  Mbps.  These  channels  can  be  subdivided  into  subchannels  to 
support  compressed  voice  and  data  (1-4  bits  per  cycle,  8-32  Kbps),  voice  or  ISDN  B-channel 
(8  bits  per  cycle,  64  Kbps),  ISDN  HO  (48  bits  per  cycle,  384  Kbps),  ISDN  HI  1  channel  (192  bits 
per  cycle,  1,536  Kbps),  and  T1  carrier  (193  bits  per  cycle,  1,544  Kbps).  [Ref.  Stallings  1993, 
p.  391-395] 

9. 5. 7. 3  FDDI  Follow-On  LAN  Standards 

Another  high-speed  version  of  FDDI,  called  FDDI  follow-on  LAN  (FFOL)  and  designed 
for  data  rates  of  622  Mbps  to  1.2  Gbps,  has  been  proposed  by  ANSI  X3T9.5.  The  general 
requirements  for  FFOL  include: 

•  The  ability  to  provide  a  backbone  for  multiple  FDDI  networks 

•  The  ability  to  provide  efficient  interconnections  to  wide  area  networks  [e.g., 
Broadband-ISDN  (BISDN)] 

•  The  ability  to  support  for  a  wide  variety  of  "integrated"  services  such  as  data, 
graphics,  video,  and  audio 

•  An  initial  data  rate  less  than  1.25  Gbps 

•  A  data  rate  matched  to  ITU-TS  Synchronous  Data  Hierarchy  (SDH),  another  fiber- 
based  system  that  provides  support  for  communication  in  the  100-  to  622-Mbps  range 
(ITU-TS  G.707,  G.708,  and  G.709)  (see  Section  9.6.1) 

•  The  ability  to  use  existing  FDDI  cable,  where  feasible. 

The  target  date  for  completion  of  the  basic  FFOL  standards  is  December  1995.  The 
estimated  life  of  the  FFOL  family  of  standards  is  10  to  15  years.  In  May  1991,  ASC  X3 
announced  the  approval  of  six  new  FFOL  projects  to  be  developed  by  ANSI  X3T9.5,  as  follows: 

•  FFOL  -  Physical  Medium  Dependent  (FFOL-PMD) 

•  FFOL  -  Physical  Layer  Protocol  (FFOL-PHY) 

•  FFOL  -  Service  Multiplexer  (FFOL-SMUX) 

•  FFOL  -  Asynchronous  Media  Access  Control  (FFOL-AMAC) 

•  FFOL  -  Isochronous  Media  Access  Control  (FFOL-IMAC) 

•  FFOL  -  Station  Management  (FFOL-SMT). 
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9.5. 7.4  Low-Cost  Fiber  FDDI  Standards  Development 

A  new  proposed  standard  for  low-cost  fiber  (LCF)  optic  connections  to  FDDI  is  under 
consideration.  This  draft  standard,  FDDI-LCF-PMD  defines  a  smaller  lower-cost  connector  and 
optical  specification  for  connections  that  are  primarily  intended  for  horizontal  cabling  from  the 
wiring  closet  to  the  desktop.  [Ref.  X3  1992j] 

9.6  Broadband  Technology 

Broadband  technology  is  based  on  the  concept  of  “fast  packet"  (see  Figure  7),  which 
appears  as  frame  relay  and  cell  relay.  Frame  relay  is  an  extension  of  circuit  switching,  whereas  cell 
relay  is  an  extension  of  packet  switching.  Frame  relay  uses  variable-length  packets  (the  frames), 
reduces  the  overhead  associated  with  circuit  switching  to  take  advantage  of  low-error-rate 
transmission  means,  and  operates  at  rates  of  up  to  2  Mbps  (compared  to  64  Kbps  for  circuit 
switching).  Frame  relay  standards  being  developed  by  ITU-TS  include  L122,  Framework  for 
Providing  Additional  Packet  Model  Bearer  Services,  for  LAPD  and  Q.931  for  ISDN  frame  relay. 
Another  example  of  frame  relay  is  the  synchronous  optical  network  (SONET),  an  ANSI  standard 
whose  counterpart  in  ITU-TS  is  known  as  synchronous  digital  hierarchy  (SDN).  [Ref. 
Stallings  1993,  pp.  243,  277-278] 

In  cell  relay,  there  are  fixed-length  frames  of  53  octets,  of  which  48  are  data  and  the  others 
are  overhead  for  error  control.  Cell  relay  is  designed  to  work  in  the  range  of  tens  to  hundreds  of 
megabits  per  second.  Examples  of  cell  relay  standards  are  ISO  8802-6  (MAN)  and  ATM  for  wide 
area  networks. 
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Figure  7.  Broadband  Technology 
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9.6.1  SONET 

The  Synchronous  Optical  Network  (SO NET)  is  an  optical  transmission  interface 
standardized  by  ANSI.  A  comparable  version,  referred  to  as  SDH  (Synchronous  Digital 
Hierarchy),  has  been  published  by  ITU-TS  in  recommendations  G.707,  G.708,  and  G.709.  Each 
is  intended  to  provide  a  specification  for  taking  advantage  of  the  high-speed  digital  transmission 
capability  of  optical  fiber.  The  SONET  specification  defines  a  hierarchy  of  standardized  digital 
data  rates,  illustrated  in  Table  17.  These  rates  are  based  on  multiples  of  3  times  810  octets 
transmitted  once  every  125  )is  (27  of  the  810  octets  are  overhead,  for  an  efficiency  of 
96.7  percent).  ANSI  designations  are  specified  in  terms  of  the  synchronous  transport  signal  level 
(STS)  and  corresponding  optical  carrier  level  (OC),  whereas  ITU-TS  designations  are  in  terms  of 
the  synchronous  transfer  mode  level  (STM).  Related  ITU-TS  recommendations  and  ANSI 
standards  are  listed  in  Table  18.  [Ref.  Stallings  1993,  pp.  300-303] 


Table  17.  SONET  Digital  Data  Ratas 


Data  Rata  (Mbpa) 

STS-1/OC-1 

- 

51.84 

STS-3/OC-3 

STM-1 

155.52 

STS-9/OC-9 

STM-3 

466.56 

STS-12/OC-12 

STM-4 

622.08 

STS-18/OC-18 

STM-6 

933.12 

STS-24/OC-24 

STM-8 

1244.16 

STS-36/OC-36 

STM-12 

1866.24 

STS-48/OC-48 

STM-16 

2488.32 

Source:  [Stallings  1993,  p.  301], 


Table  18.  ITU-TS  Racommendationa  and  ANSI  Standards  on  SONET 


Subject 

ITU-TS  G.707  to  G.709 

SDH  Ratas  and  Format 

ITU-TS  G.781  to  G.784 

Equipment  Functions 

ITU-TS  G.957 

Optical  Interfaces 

ITU-TS  G.958 

Line  Systems 

ITU-TS  G.803 

Network  Architecture 

ITU-TS  G.831 

Management  Capabilities 

ITU-TS  G.774 

Management  Information  Model 

ANSI  T1.105 

SONET  Rates  and  Format 

ANSI  T1.106 

Optical  Parameters  (superseded  by  G.957  and  TR  253) 

ANSI  T1 .11 7 

Optical  Parameters-Short  Reach 

ANSI  T1. 118 

OAM&P  Communications 

Source:  (5avidson  1991,  p.78). 


SONET  addresses  the  incompatibility  of  European  and  North  American  schemes  for  high- 
data-rate  transmissions  (in  excess  of  the  ANSI  DS3  44.736-Mbps  level)  in  optical  systems  by 
providing  a  standardized  hierarchy  of  multiplexed  digital  transmission  rates  that  accommodates 
both  the  ITU-TS  and  North  American  existing  rates.  SONET  also  addresses  the  need  for 
economic  access  to  small  amounts  of  traffic  within  the  bulk  payload  of  an  optical  signal  by 
introducing  a  new  approach  to  time-division  multiplexing.  Further,  SONET  addresses  the  need  for 
a  major  increase  in  network  management  capabilities  within  the  synchronous  time-division  signal 
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to  enable  services  such  as  virtual  private  networking,  time-of-day  bandwidth  allocation,  and 
support  of  the  broadband  ISDN  ATM  technique.  [Ref.  Stallings  1993,  p.  300] 

The  basic  SONET  building  block  is  the  STS-1  frame,  which  consists  of  810  bytes  and  is 
transmitted  once  every  125  its,  for  an  overall  data  rate  of  51.84  Mbps.  The  Erst  27  octets  of  the 
frame  are  devoted  to  overhead,  with  9  octets  devoted  to  section-related  overhead  and  18  octets 
defining  various  fields.  The  remainder  of  the  frame  is  payload.  STM-1  (155.52)  is  the  lowest 
nU-TS  level,  as  it  is  the  lowest-rate  signal  that  can  accommodate  the  ITU-TS  level-four  signal  of 
139.264  Mbps.  [Ref.  Stallings  1993,  pp.  300-303] 

9.6.2  BISDN 

Broadband  ISDN  (BISDN)  provides  a  wide  range  of  services  through  flexible  user- 
network  interfaces  over  a  limited  number  of  connection  types.  BISDN  can  include  a  switched  or 
non-switched  network  connection.  BISDN  supports  all  the  64-kbps  transmission  services,  both 
circuit-switching  and  packet  switching,  provided  by  ISDN  and,  in  addition,  provides  for  higher- 
data-rate  transmission  services.43  The  fast-packet-switching  technique  of  BISDN  readily  supports 
the  user-network  interface  protocol  known  as  asynchronous  transfer  mode  (ATM). 

The  BISDN  can  offer  different  forms  of  applications  and  communications  capabilities.  The 
communications  and  applications  could  support  distribution  oriented  services  and/or  interactive 
services.  These  services  include:  conversational,  messaging,  retrieval  services,  and  distribution 
services  with  and  without  individual  presentation  control.  Conversational  services  are  those 
services  that  provide  bidirectional  (although  unidirectional  could  be  included)  dialogue 
communications.  These  services  could  include  video  surveillance,  video-telephony,  video 
teleconference,  and  high  speed  data  communications. 

Message  services  are  the  ’’typical"  mail  functions  extended  to  films  or  moving  pictures, 
high  resolution  images,  and  audio  information.  These  services  allow  a  user  to  create,  edit, 
process,  convert,  store,  and  forward  messages.  This  service  allows  end  users  to  communicate 
with  each  other. 

Retrieval  services  allow  an  end  user  to  retrieve  information  from  a  "central"  location  or 
archive  site.  The  information  could  be  film,  high  resolution  image,  or  audio  information.  The 
information  is  retrieved  on  demand.  The  archive  site  only  delivers  requested  information. 

Distribution  services  can  exist  with  or  without  individual  presentation  control.  Distribution 
services  without  individual  presentation  control  include  broadcast  services  for  television.  A 
television  viewer  can  select  a  channel,  but  has  no  control  over  the  presentation.  The  start  and 
finish  of  the  presentation  is  under  the  control  of  the  distribution  service.  A  distribution  service 
with  individual  presentation  control  broadcasts  in  a  cyclic  manner.  Upon  user  selection,  the  user 
receives  the  presentation  from  its  beginning. 

9.6.3  Asynchronous  Transfer  Mode  (ATM) 

Sometimes  known  as  cell  relay,  ATM  was  developed  for  use  with  Broadband  ISDN, 
which,  as  noted  above,  is  based  on  optical  fiber  cable  and  is  intended  to  support  transfer  of  voice, 
data,  and  video  at  rates  on  the  order  of  150  Mbps  (applications  on  the  order  of  600  Mbps  are  also 
being  considered).  ATM  is,  in  effect,  a  packet-oriented  protocol  based  up<  n  a  relatively  short. 


43  Note  that  ISDN  concepts  include  broadband — (be  terminology  B-ISDN  exists  only  to  focus  attention  on  tbe 
broadband  aspects  of  ISDN,  which  can  handle  audio,  video,  and  data  communications.  ISDN  is  discussed  in 
connection  with  the  Network  Layer  in  Section  9.7.6.  ISDN  standards  are  listed  in  Section  II.B  of  Appendix  E. 
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fixed-length  frame  (called  a  cell),  supporting  a  hierarchical  structure  of  virtual  channels  and  virtual 
paths  (that  contain  one  or  more  virtual  channels),  over  multiple  physical  links.  The  ATM  is  a 
connection-oriented  technique  that  can  be  used  to  support  both  connection-oriented  and 
connectionless  services.  Signalling  (such  as  call  set  up  and  clear)  and  user  information  are  carried 
on  separate  virtual  channels.  ATM  is  designed  to  offer  a  flexible  transfer  capability  common  to  all 
services. 

The  ATM  standard  is  being  developed  by  ITU-TS  SGXVm.  Although  ATM  assumes  an 
optical  fiber  physical  medium,  other  media  are  being  considered  for  ATM  use  including  satellite 
transmission.  The  size  (48  octets)  of  the  payload  for  each  ATM  cell  is  a  compromise  between  a 
larger  size  (64  octets)  favored  by  the  United  States  and  Japan  and  a  small  size  (16  octets)  favored 
by  representatives  from  Europe. 

9.6.3. 1  ATM  Model 

Figure  8  is  an  illustration  of  the  protocol  architecture  for  BISDN  that  shows  the  two  layers 
for  ATM.  These  layers  are  the  ATM  layer  and  the  ATM  adaptation  layer  (AAL).  The  ATM  layer 
provides  generic  flow  control,  cell-header  generation  and  extraction,  cell  virtual  path  identifier 
(VPI)  and  virtual  channel  identifier  (VCI)  translation,  and  cell  multiplexing  and  demultiplexing. 
(Network  management  for  ATM  is  simplified  by  dividing  the  transmission  path  into  one  or  more 
virtual  paths,  each  of  which  is  subdivided  into  one  or  more  virtual  channels.)  These  functions  are 
common  to  all  services  that  provide  packet-transfer  capabilities,  whereas  the  AAL  is  service 
dependent  The  AAL  maps  higher-layer  information  into  ATM  cells  and  collects  information  from 
ATM  cells  for  delivery  to  high  layers.  The  functions  provided  by  the  AAL  (for  which  there  are 
corresponding  sublayers)  are  convergence  (CS)  and  segmentation  and  reassembly  (SAR).  The 
AAL  supports  information-transfer  protocols  not  based  on  ATM,  such  as  pulse  code  modulation 
(PCM)  and  LAPD  (e.g.,  using  SAR  to  map  LAPD  frames  into  ATM  packets  and  recover  the 
LAPD  frames  after  transmission).  [Ref.  ITU-TS  1.121:1990;  Stallings  1993,  p.  274,  279] 

ITU-TS  1.413:1990  specifies  two  approaches  to  the  physical  layer  for  155.52-Mbps 
interface:  one  that  is  cell-based  and  one  that  is  SDH  (SONET)-based.  For  the  cell-based  physical 
layer,  no  framing  is  imposed — the  interface  structure  consists  of  a  continuous  stream  of  53-octet 
cells.  The  SDH-based  physical  layer  uses  the  STM-1  (STS-3/OC-3)  810-octet  frame  (see 
Section  9.6.1). 

The  model  specifies  three  planes  orthogonal  to  the  layers  [Ref.  Stallings  1993,  p.  274- 

275]: 

•  User  plane — provides  for  user  information  transfer,  along  with  associated  controls 
(e.g.,  flow  control,  error  control) 

•  Control  plane — performs  call-control  and  connection-control  functions 

•  Management  plane — includes  plane  management,  which  performs  management 
functions  related  to  a  system  as  a  whole  and  provides  coordination  between  all  the 
planes;  and  layer  management,  which  performs  management  functions  related  to 
resources  and  parameters  residing  in  its  protocol  entities. 


Chapter  9 


156 

UNCLASSIFIED 


Network  Service  Standards 


UNCLASSIFIED 


Figure  8.  ATM  Protocol  Reference  Model 


9. 6. 3. 2  ATM  Support  of  Military  Features 

In  its  analysis  of  ATM,  MITRE  has  noted  the  following  with  regard  to  military  features  for 
ATM  [Ref.  MITRE  1990]: 

•  The  protocol  is  flexible  and  efficient  Since  it  is  designed  for  a  highly  reliable  physical 
medium  (fiber  optic  cable),  it  may  be  unsuitable  for  some  tactical  media.  The  ATM 
could  operate  over  a  low  bandwidth  medium.  The  two  major  areas  that  might  preclude 
ATM  from  use  in  the  tactical  environment  are: 

ATM  may  be  inefficient  in  sending  short  cells  over  a  medium  in  which 
synchronization  is  difficult  such  as  combat  net  radio.  Further,  the  short  cell  size 
could  require  multiple  short  messages  when  a  more  optimal  length  would  be  more 
efficient 

The  ATM  error  detection  and  correction  capability  may  be  inadequate.  There  is  an 
eight-bit  cyclic  redundancy  check  for  the  header  and  a  separate  ten-bit  cyclic 
redundancy  check  for  the  user  information  field.  Only  a  single  bit  for  forward 
error  correction  capability  on  the  header  as  well  as  on  the  user  information  is 
provided. 

•  There  is  no  provision  within  ATM  for  precedence  and  preemption;  however,  these 
features  could  be  achieved  at  higher  layers  over  ATM. 

•  ATM  would  be  reasonably  efficient  for  real-time  communication,  except  that  messages 
requiring  multiple  cells  create  the  extra  overhead  of  additional  transmissions  and 
reassembly. 

•  Nothing  in  the  ATM  addresses  security  or  network  management.  Network 
management  functions  are  assumed  to  take  place  by  the  layer  or  system  manager, 
which  has  interfaces  at  each  sublayer. 

•  Nothing  in  the  ATM  precludes  features  such  as  multimode  end-systems  or  mobile 
hosts. 

•  There  is  no  provision  for  multi-peer  data  transmission  or  multi-casting. 

9.6.4  Frame  Relay  Technology 

ITU-TS  Recommendation  1.122,  entitled  Framework  for  Providing  Additional  Packet 
Mode  Bearer  Services,  introduced  a  new  form  of  packet  transmission  that  has  become  one  of  the 


Chapter  9 


157 

UNCLASSIFIED 


Network  Service  Standards 


UNCLASSIFIED 


most  significant  contributions  of  ISDN  work.  This  new  technique  is  now  generally  referred  to  as 
frame-mode  bearer  service  (FMBS)  or  frame  relay.  Like  cell  relay  (ATM)  and  X.25,  frame  relay 
allows  multiple  logical  connections  to  be  multiplexed  over  a  single  physical  interface.  As  with  cell 
relay,  there  is  no  link-by-link  error  control  or  flow  control  with  frame  relay.  Frame  relay  has 
higher  overhead  than  cell  relay  (due  to  the  variable-length  packets  of  frame  relay)  and  its  data  rate  is 
limited  to  about  2  Mbps  (whereas  cell  relay  operates  at  10-100  Mbps).  [Ref.  Stallings  1993, 
pp.  243, 277-278] 

ITU-TS  has  published  the  following  frame  relay  recommendations: 

•  L223. 1 — ISDN  Frame  Mode  Bearer  Services  ( FMBS)  -  ISDN  Frame  Relaying  Bearer 
Services 

•  1.223.2 — ISDN  Frame  Mode  Bearer  Services  (FMBS)  -  ISDN  Frame  Switching 
Bearer  Service 

•  1.370 — Congestion  Management  for  the  ISDN  Frame  Relaying  Bearer  Service 

•  L372 — Frame  Relaying  Bearer  Service  Network-to-Network  Interface  Requirements 

•  L501 — Frame  Mode  Bearer  Services  ( FMBS)  Interworking. 

Work  on  frame  relay  in  the  United  States  uses  a  data  rate  of  1.544  Mbps,  with  future 
growth  to  45  Mbps.  ANSI  has  developed  three  draft  standards  [Ref.  Stallings  1993,  p.  243]: 

•  T1 .606 — Architectural  Framework  and  Service  Description  for  Frame-Relaying  Bearer 
Service 

•  T1.617 — Signalling  Specification  for  Frame  Relay  Bearer  Service 

•  T1.618 — Core  Aspects  of  Frame  Protocol  for  Use  with  Frame  Relay  Bearer  Service. 

Frame  relay  specifications  cover  two  major  areas:  call  control  and  user  data  transfer. 
Frame  relay  connections  may  be  permanent,  in  which  case  call  control  is  not  required.  For 
switched  frame  relay  connections,  a  separate  call-control  connection  is  used,  providing  efficient 
out-of-band  signalling.  The  data  transfer  of  frame  relay  specification  calls  for  a  two-layer  protocol 
architecture,  the  physical  and  data  link  layers.  End-system  addressing  and  connection  multiplexing 
are  done  at  Layer  2.  [Ref.  Stallings  1993,  p.  269] 

The  key  areas  in  which  frame  relaying  differs  from  a  conventional  X.25  packet-switching 
service  are  the  following  [Ref.  Stallings  1993,  p.  245]: 

•  Call-control  signalling  is  carried  on  a  separate  logical  connection  from  user  data. 
Thus,  intermediate  nodes  need  not  maintain  state  tables  or  process  messages  relating  to 
call  control  on  an  individual  per-connection  basis. 

•  Multiplexing  and  switching  of  logical  connections  takes  place  at  Layer  2  instead  of 
Layer  3,  eliminating  one  entire  layer  of  processing. 

The  protocol  architecture  for  frame  relay  is  based  on  two  separate  planes  of  operations:  a 
control  (C)  plane,  which  is  involved  in  the  establishment  and  termination  of  logical  connection,  and 
a  user  (U)  plane,  which  is  responsible  for  the  transfer  of  user  data  between  subscribers.  Thus, 
C-plane  protocols  are  between  a  subscriber  and  the  network,  whereas  U- plane  protocols  provide 
end-to-end  functionality.  [Ref.  Stallings  1993,  p.  246] 

For  the  actual  transfer  of  information  between  end  users,  the  U-plane  protocol  is  Q.922. 
Only  the  core  functions  of  Q.922  are  used  for  frame  relay.  The  core  functions  of  Q.922  in  the 
U-plane  constitute  a  sublayer  of  the  data  link  layer.  This  provides  the  bearer  service  of  transferring 
data  link  frames  from  one  subscriber  to  another,  with  no  flow-control  or  error  control.  Above  this, 
the  user  may  choose  to  select  additional  data  link  or  network  layer  end-to-end  functions.  In  the 
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control  plane,  Q.922  is  used  to  provide  a  reliable  data  link  control  service,  with  error  control  and 
flow  control,  for  the  delivery  of  I.451/Q.931  messages.  [Ref.  Stallings  1993,  p.  247] 

Because  of  the  simplicity  of  the  frame  relay  protocol,  there  are  no  mechanisms  for 
traditional  data  link  error  and  flow  control.  Thus,  a  frame-relay  network  is  vulnerable  to 
congestion.  To  compensate  for  this,  simple  congestion  avoidance  and  congestion  recovery 
mechanisms  are  built  into  the  protocol.  [Ref.  Stallings  1993,  p.  269] 

9.7  Network  Layer  Standards 

The  purpose  of  the  Network  Layer  is  to  provide  a  means  for  network  service  users  to 
communicate  without  any  concern  for  the  topology  of  the  network  and  the  transmission  media  used 
in  each  constituent  subnetwork  that  constitute  the  network.  The  Network  Layer  achieves  this  by 
performing  functions  such  as  routing  and  relaying.  Due  to  a  variety  of  networking  technologies 
and  complex  configurations  of  subnetworks,  the  operation  of  the  Network  Layer  is  very 
complicated,  sometimes  involving  the  use  of  more  than  one  network  protocol.  The  network 
protocols  for  interconnection  are  based  on  the  Internal  Organization  of  the  Network  Layer  (IONL) 
model.  The  routing  protocols  are  based  on  the  OSI  Routing  framework,  which  is  specified  in 
ISO/IEC  TR  9575  and  provides  a  framework  to  partition  the  routing  functions.  [Ref. 
Tang  1992,  p.  107] 

General  standards  for  the  Network  Layer  are  listed  in  Table  19.  There  are  two  modes  of 
network  services  [Ref.  Tang  1992,  p.  107]: 

•  Connection-oriented  network  service  (CONS) — the  connection-oriented  exchange  of 
data  that  provides  for  connection  establishment,  data  transfer,  and  connection 
termination  (as  with  all  connection-oriented  services);  receipt  confirmation,  expedited 
data,  and  quality  of  service 

•  Connectionless-mode  network  service  (CLNS) — that  connectionless  exchange  of  data 
that  supports  actions  such  as  discarding  data  units,  duplicating  data  units,  and 
delivering  data  units  in  a  different  order  than  the  order  in  which  they  were  presented  by 
the  user.  In  addition,  these  services  can  be  optionally  qualified  as  follows:  objects 
will  be  discarded  only  after  a  stated  time,  objects  must  be  discarded  no  later  than  a 
stated  time,  objects  will  be  discarded  only  if  more  than  a  certain  number  of  objects  are 
in  the  queue,  objects  will  not  be  discarded,  the  order  of  the  objects  in  the  queue  will 
not  be  changed,  and  objects  will  not  be  duplicated. 
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ISO  8648 
ISO/1  EC  8880-1 

ISO/IEC  8880-2 

DAM  1 
PDAM2 
ISO/IEC  8880-3 

WD  8880-4 

ISO/IEC  TR  9577 
ISO/IEC  TR 10172 
ISO/IEC  10177 

ISO/IEC  10733 

WD  10778 

DIS  11577 
ITU-TST.70 
ITU-TS  X21 3 
rru-TS  xsoo 

ITU-TS  X.301  Rw  1 

rru-TS  x.302 


ITU-TS  X305 


ITU-TS  X.310 

ITU-TS  X.320 

ITU-TS  X.321 

rru-TS  X322 

rru-TS  X323 
rru-TS  X.324 

rru-TS  X.325 

rru-TS  X.326 

rru-TS  X327 


Table  19.  Ganaral  Standards  for  ths  Network  Layer 


Network Service  Definitiofl,  Edition 2 

Internal  Organization  of  the  Network  Layer,  February  1988 

Protocol  Combination  to  Provide  and  Support  the  OSI  Network  Service,  Part  1:  General 
Principles 

Protocol  Combination  to  Provide  and  Support  the  OSI  Network  Service,  Part  2:  Provision 

and  Support  of  the  Connection-Mode  Network  Service 

Addition  of  the  ISDN  Environment 

Addition  of  the  PSTN  and  CSDN  Environments 

Protocol  Combination  to  Provide  and  Support  the  OSI  Network  Service,  Part  3:  Provision 
and  Support  of  tits  Connectionless-Mode  Network  Service 

Protocol  Combination  to  Provide  and  Support  the  OSI  Network  Service,  Part  4: 
Interconnection  of  OSI  Environments 
Protocol  Identification  in  the  OSI  Network  Layer 
Network/Transport  Protocol  Interworking  Specification 

Intermediate-System  Support  of  the  OSI  Connection-Mode  Network  Service  Using  ISO  8208 
in  Accordance  with  ISO  10028 

Elements  of  Management  Information  Related  to  OSI  Network  Layer  Standards  [SC21  N 
5560,  SC6  N  6413] 

High-Speed  Integrated  Services  Networks  and  User/Network  Interface  to  High-Speed 
Integrated  Services  Networks 
Network  Layer  Security  Protocol 

Network-Independent  Basic  Transport  Service  for  the  Telematic  Services 
Network  Service  Definition  for  OSI  for  CCITT  Applications 

General  Principles  and  Arrangements  for  Interworking  Between  Public  Data  Networks,  and 
Between  PDNs  and  Other  Public  Networks 

Description  of  the  General  Arrangement  for  Call  Control  Within  a  Subnetwork  and 
Between  Subnetworks  for  the  Provision  of  Data  Transmission 

Description  of  the  General  Arrangement  for  Internal  Network  Utilities  Within  a  Subnetwork 
and  Immediate  Utilities  Between  Subnetworks  for  the  Provision  of  Data  Transmission 
Services 

Functionalities  of  Subnetworks  Relating  to  the  Support  of  the  OSI  Connection-Mode  Network 
Service 

Procedures  and  Arrangements  for  DTE  Accessing  Circuit  Switched  Digital  Data  Services 
Through  Analogue  Telephone  Networks 

General  Arrangements  for  Interworking  Between  ISDNs  for  the  Provision  of  Data 
Transmission  Services 

General  Arrangements  for  Interworking  Between  Circuit  Switched  Public  Data  Networks 
(CSPDNs)  and  ISDNs  for  the  Provision  of  Data  T ransmission  Services 
General  Arrangements  for  Interworking  Between  Packet  Switched  Public  Data  Networks 
(PSPDNs)  and  CSPDNs  for  the  Provision  of  Data  Transmission  Services 
General  Arrangements  for  Interworking  Between  PSPDNs 

General  Arrangements  for  Interworking  Between  PSPDNs  and  Public  Mobile  Systems  for  the 
Provision  of  Data  Transmission  Services 

General  Arrangements  for  Interworking  Between  PSPDNs  and  ISDNs  for  the  Provision  of 
Data  Transmission  Services 

General  Arrangements  for  Interworking  Between  PSPDNs  and  Common  Channel  Signalling 
Network  (CCSN) 

General  Arrangements  for  Interworking  Between  PSPDNs  and  Private  Data  Networks  for  the 
Provision  of  Data  Transmission  Services 


ISO  8880-2  specifies  the  protocols  that  are  to  be  used  to  support  the  connection-mode 
network  service  over  a  variety  of  subnetworks.  This  is  illustrated  in  Figure  9.  This  protocol  is  an 
extension  of  X.2S  that  allows  both  DTE-DTE  and  DTE-DCE  modes  of  operation.  In  effect,  every 
type  of  subnetwork  is  convened  to  an  X.25  subnetwork,  and  the  virtual  circuit  capability  is  used  to 
provide  network  connections.  [Ref.  Stallings  1993,  p.  103] 
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Conncction-Modo  Network  Service*  (ISO  8348) 

I 

X.25  Packet  Laval  Protocol  for  DTE  (ISO  8208) 

#  I - 

8802  LANS  PSON 

I  I 

8808  In  the  8208  in  the 

DTE -DTE  mode  DTE-DCE  mode 

over  LLC  over  HOLC 

(ISO  8802-2)  (ISO  7776) 

Source:  [Stall Inga  1993.  p.  104]. 

Figure  9.  Connection-Oriented  Mode  Network  Service 

ISO  8880-3  specifies  the  protocols  that  are  to  be  used  to  support  the  connectionless-mode 
network  service  over  a  variety  of  subnetworks.  Key  standards  are  shown  in  Figure  10;  a  complete 
list  of  Network  Layer  standards  is  provided  in  Section  IV  of  Appendix  D.  The  network  protocol 
can  be  used  across  a  single  subnetwork.  However,  the  protocol  was  specifically  designed  to 
provide  a  connectionless  internetworking  capability  that  would  ride  on  top  of  a  variety  of 
subnetwork  protocols.  [Ref.  Stallings  1993,  p.  103] 

Connectionless-Mode  Network  Services  (ISO  8348:1993) 

I 

Protocol  for  Providing  the  Connectionless-Mode  Network  Service  (ISO  8473) 


PSCN  CSON  Point-to-Pomt 

I  I 

ISO  8473  over  8473  w„  8473  w#r 

ISO  8208  in  the  HDLC  HOLC 

DTE-DCE  mode  (ISO  7776)  (ISO  7776) 

Source:  [Stallngs  1993,  p.  104]. 

Figure  10.  Connectionless-Mode  Network  Service 
9.7.1  X.25  Packet  Layer 

The  X.25  packet-switched  network  access  standard  was  originally  approved  in  1976  and 
subsequently  has  been  revised  in  1980  and  1984.  This  standard  specifies  a  DTE-DCE  interface. 
In  the  case  of  X.25,  the  DCE  provides  access  to  a  packet-switched  network.  The  standard 
specifies  three  levels  as  illustrated  in  Figure  11:  physical  level,  link  level,  and  packet  level.  [Ref. 
Stallings  1993,  p.  1 13] 
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Figure  11.  X.25  Packet-Switched  Network  Ace— «  Standard 


For  the  physical  level  the  standard  is  X.21  and  optionally  X.21  bis.  The  link  level  makes 
use  of  LAPB  over  a  single  physical  link  between  DTE  and  DCE,  and  optionally  there  may  be 
multiple  physical  links  between  a  DIE  and  its  DCE.  The  packet  level  specifies  a  virtual-circuit 
service.  A  compatible  version  of  the  packet-level  standard  has  been  issued  by  the  ISO  (ISO  8208). 
[Ref.  Stallings  1987,  p.  113] 

The  virtual  circuit  service  of  X.25  provides  for  two  types  of  virtual  circuit:  virtual  and 
permanent  virtual  call  The  virtual  call  is  a  dynamically  established  virtual  circuit  using  call  setup 
and  call  clearing  procedure.  A  permanent  virtual  circuit  is  a  permanent,  network-assigned  virtual 
circuit  Data  transfer  occurs  as  with  virtual  calls,  but  no  call  setup  or  clearing  is  required.  [Ref. 
Stallings  1987,  p.  114] 

Control  packets  include  a  virtual  circuit  number,  a  packet  type  identifier,  and  additional 
information  pertinent  to  the  particular  control  function.  Standards  for  X.25  packet  switching  are 
listed  in  Table  20.  [Ref.  Stallings  1987,  p.  117] 

9.7.2  Connection-Oriented  Network  Protocol 

The  connection-oriented  network  protocol  (CONP)  is  designed  to  meet  the  following 
requirements  of  internetworking  service  [Ref.  Tang  1992,  p.  106]: 

•  The  details  of  an  internetworking  operation  and  the  subnetwork  facilities  should  be 
transparent  to  the  network  service  users. 

•  The  networking  service  should  allow  two  communicating  network  service  users  to 
negotiate  on  QoS  and  other  options  during  connection  establishment. 

•  The  network  service  users  should  have  a  uniform  and  unambiguous  way  to  address 
each  other  using  some  network  addressing  scheme. 

Peer  network  service  users  such  as  transport  entities  use  a  confirmed  service  element 
(N-CONNECT)  to  set  up  a  network  connection.  During  connection  establishment,  the  expedited 
data  selection,  the  receipt  confirmation  selection,  and  the  QoS  parameters  are  negotiated.  The 
expedited  data  selection  parameter  is  used  to  determine  whether  expedited  data  can  be  sent  in  the 
network  connection.  The  receipt  confirmation  selection  parameter  is  used  to  determine  whether  a 
sender  can  solicit  acknowledgment  for  some  data  units.  This  parameter  is  particularly  useful  when 
the  underlying  subnetworks  are  unreliable.  Both  the  expedited  data  and  the  receipt  confirmation 
are  optional  features  that  do  not  have  to  be  implemented  by  the  service  provider.  Within  the 
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constraints  imposed  by  the  services  of  the  intervening  subnetworks,  the  network  service  provider 
tries  to  provide  the  requested  QoS.  Some  of  the  QoS  parameters  such  as  throughput  and  transit 
delay  are  subnetwork  dependent  while  others  such  as  protection  and  priority  are  not.  [Ref. 
•  Tang  1992,  p.  108] 

Table  20.  Standards  for  X.25  Packet  Switching 


ISO  8208*  X25  hack*  Level  Protocol  (PLP)  for  DTE  ' 

AM  1  Alternative  Logical  Channel  Number  Allocation 

PQAD2  Extension*  for  Private  Switched  Us* 

AM  3  Static  Conformance  Requirements 

ISO  8878  Use  of  X.25  to  Provide  the  OSI  Connection-Mode  Network  Service 

ISO  8878-2  Use  of  X.25  to  Provide  the  OSI  Connection-Mode  Network  Service,  Part  2:  Protocol 

Implementation  Conformance  Statement  (PICS) 

ISCVIEC  8881  Use  of  the  X.25  Packet  Level  Protocol  (PLP)  in  Local  Area  Networks 

ISO  8882  X25-DTE  Conformance  Testing,  Part  1:  General  Principles 

CXS  8882-1  X25-DTE  Conformance  Testing,  Part  1 :  General  Principles,  Etftion  2  of  ISO  8882 

ISCVIEC  8882-2  X25-DTE  Conformance  Testing,  Part  2:  Data  Link  Conformance  Teat  Suite 
ISCVIEC  8882-3  X25-DTE  Conformance  Testing,  Part  3:  Packet  Level  Conformance  Teat  Suite 
ISGWEC  10588  Ueeof  lheX25  PLP  in  Conjunction  with  X21/X21  bis  to  Provide  OSI  CONS 

ISCVIEC  10732  Use  of  the  X2S  PLP  to  Provide  OSI  CONS  Over  Telephone  Network 

mJ-TS  X25  Interface  Between  DTE  and  DCE  for  Terminals  Operating  in  the  Packet  Mode  and  Connected 
to  Public  Date  Networks  by  Dedicated  Circuit 
mj-TS  X75  Terminal  and  Transit  Cal  Control  Procedures  and  Data  Transfer  System  on  International 
Circuits.  Between  PSDNs 

ITU-TS  X223  Use  of  X25  to  Provide  the  OSI  Connection-Mode  Network  Service  for  CCITT  Applications 
(see  ISO  8878) 

mj-TS  X244  Procedure  for  the  Exchange  of  Protocol  Identification  During  Virtual  Call  Establishment  on 
Packet  Switched  Public  Data  Networks 

ITU-TS  X612  Provision  of  the  OSI  Connection-Mode  Network  Service  by  Packet  Mode  Terminal 
Equipment  Connected  to  an  Integrated  Services  Digital  Network  (ISDN)  for  CCITT 
Applications _ _ _ 


CONS  can  also  be  provided  over  a  LAN.  In  a  LAN  environment  where  every  DTE  is 
attached  directly  to  the  transmission  medium,  there  is  no  identifiable  DCE  and  thus  communication 
of  Layer  2  or  above  is  DTE-to-DTE  oriented.  ISCVIEC  8881  defined  a  protocol  to  enhance  the 
service  of  LLC2.  Essentially  this  protocol  specifies  the  use  of  X.25  in  die  DTE-to-DTE  mode  in  a 
LAN  environment  In  the  DTE-to-DTE  mode,  a  call  request  packet  and  an  incoming  call  arc 
practically  the  same,  and  a  call  accepted  packet  and  a  call  connected  packet  are  also  practically  die 
same.  [Ref.  Tang  1992,  p.  110] 

9.7.3  Connectionless  Network  Protocol 

The  connectionless  network  protocol  (CLNP)  (ISO  8473)  is  a  subnetwork  independent 
convergence  protocol,  providing  the  network  service  over  a  well-defined  set  of  underlying 
capabilities  that  need  not  be  based  on  the  characteristics  of  any  particular  subnetwork.  CLNP 
assumes  minimal  services  from  the  underlying  subnetwork,  which  may  be  connection-oriented  or 
connectionless.  CLNP  may  run  on  top  of  a  LAN  or  a  WAN.  The  protocol  data  unit  used  by 
CLNP  is  called  an  internet  protocol  (IP)  datagram,  which  can  contain  user  data  of  up  to  64  kbytes. 
[Ref.  Tang  1992,  pp.  110-125] 
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9.7.4  Internet  (TCP/IP)  Standards 

Hie  US  military  has  developed  and  widely  implemented  (e.g.,  in  the  Defense  Data 
Network)  unique  Internet  protocols  for  Layers  3  and  4  that  are  not  OSI  conformant  These 
protocols  will  serve  as  a  costandard  for  the  US  DoD  until  transition  to  OSI  is  complete.  These 
protocols  are  identified  since  they  will  be  implemented  in  the  transition  strategy  for  tactical  data 
systems  to  be  fielded  in  the  1990s  by  the  US  Army.  [Ref.  Army  1989]  Details  are  provided  in 
Chapter  17.  A  connection-oriented  transport  service  (COTS)  is  provided  by  the  Transmission 
Control  Protocol  (TCP),  which  provides  end-to-end  reliability,  and  a  connectionless-mode 
network  service  is  provided  by  the  Internet  Protocol  (IP).  The  IP  provides  connectivity  over 
diverse  network  technologies.  Appendix  H  provides  a  list  of  the  standards  for  TCP/IP,  including 
the  US  military  standards  (MIL- STDs)  and  the  requests  for  comment  (RFCs). 

Historically,  TCP/IP  arose  to  meet  the  need  for  reliable  transmission  of  information  over 
media  that  did  not  guarantee  reliable,  error-free  delivery  of  information  (e.g.,  Ethernet,  Packet 
Radio,  and  Satellite).  The  Defense  Advanced  Research  Projects  Agency  (DARPA)  sponsored 
research  into  survivable  multi-media  packet  networking  in  order  to  improve  the  only  then-existing 
network,  ARPANET.  This  research  resulted  in  the  US  DoD  sponsored  Internet  suite  of  protocols. 

TCP/IP  corresponds  to  Layers  3-4  of  the  OSI  model.  In  terms  of  network  service,  the 
closest  comparison  is  between  the  connectionless  network  service  (CLNS)  and  the  service  offered 
by  the  IP.  While  the  services  offered  by  the  OSI  CO-mode  TP4  and  the  TCP  are  similar,  three 
major  d  T;rences  exist: 

•  The  TCP  service  is  stream-oriented,  whereas  the  OSI  transport  service  is  packet- 
oriented. 

•  The  TCP  service  offers  a  graceful  release,  whereas  the  OSI  offers  this  release  in  the 
session  service. 

•  The  TCP  has  an  urgent  data  facility,  whereas  the  OSI  has  an  expedited  data  service. 

One  of  the  commonly  used  protocols  for  the  Internet  is  the  Point-to-Point  Protocol  (PPP). 

The  PPP  is  defined  by  the  following  Internet  RFCs: 

•  RFC  1171,  Point-to-Point  Protocol  for  the  Transmission  of  Multi-Protocol  Datagrams 
over  Point-to-Point  Links,  July  1990 

•  RFC  1 172,  The  Point-to-Point  Protocol  (PPP)  Initial  Configuration  Options,  1990 

•  RFC  1377,  The  PPP  OSI  Network  Layer  Control  Protocol  (OSINLCP), 
November  1992. 

The  major  emphasis  of  the  Internet  suite  is  on  the  connection  of  diverse  network 
technologies  (Layers  1-4).  In  addition,  several  applications  for  use  in  the  Internet  suite  are 
available  (see  Appendix  H;  for  a  more  complete  listing  see  [Ref.  Reynolds  1987]): 

•  Simple  Mail  Transfer  Protocol  (SMTP) 

•  File  Transfer  Protocol  (FTP) 

•  TELNET 

•  Domain  Name  System  (DNS) 

•  Simple  Network  Management  Protocol  (SNMP)  (see  Section  12.1.9). 

These  services  are  the  analogs  of  MHS,  FT AM,  VT,  Directory,  and  CMIP,  respectively. 
All  of  the  Internet  application  protocols  are  rather  simple.  They  offer  a  basic  level  of  service  and 
have  a  very  narrow  scope.  The  OSI  applications  are,  in  general,  functionally  more  capable  than  the 
corresponding  applications  in  the  Internet  suit  [Ref.  Rose  1990]  In  fact,  the  US  Government,  as 
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well  as  manufacturers  and  users,  endorse  OSI  rules  at  the  upper  layers  while  preserving  the 
established  TCP/IP  networks  for  the  transport  of  information.  [Ref.  OSN  1990h]  Observers  at  the 
INTEROP  90  Conference  and  Exhibition  held  in  San  Jose,  California,  in  October  1990  noted  a 
shift  away  from  pure  TCP/IP  topics  in  contrast  to  the  previous  year  where  strongly  divided 
feelings  about  the  merits  of  OSI  versus  TCP/IP  were  revealed  [Ref.  OSN  1990g].  Until  recently, 
TCP/IP  has  been  a  de  facto  UK  standard.  However,  an  IS  notice  [Ref.  CCTA  1991]  issued  by  the 
UK  Central  Computer  and  Telecommunications  Agency  (CCTA)  of  HM  Treasury  included  an 
annex  entitled  Towards  Open  Systems:  TCP/IP  to  OSI  Migration,  which  provided  a  Statement  of 
Direction  for  use  by  UK  Government  Departments: 

It  is  an  inevitable  consequence  of  the  move  to  utilize  open  systems  standards  that 
UK  Government  departments,  in  common  with  other  European  Public  Sector 
procurement  agencies,  require  the  communications  and  network  products  that  they 
procure  to  conform  to  relevant  OSI  standards.  Departments  are  therefore  advised  to 
make  the  relevant  OSI  standards  a  mandatory  condition  of  a  procurement  for 
communications  systems  where  the  availability  of  appropriate  standards  and 
products  can  be  confirmed  However,  where  such  availability  is  questionable, 
conformance  to  relevant  OSI  standards  will  probably  be  made  a  desirable  option, 
but  tenders  that  incorporate  OSI  standards-based  solutions  will  be  viewed  as  a  more 
acceptable  solution  in  any  evaluation  of  "OSI  versus  TCP/IP"  bids. 

IBM's  networking  and  distributed  computing  strategy  into  the  next  century  includes  a  long¬ 
term  commitment  to  the  de  facto  TCP/IP  alongside  the  de  jure  OSI  standards.  Originally,  it  saw 
TCP/IP  as  a  short-term  stop-gap  until  OSI  became  more  established.  However,  since  OSI  took  off 
more  slowly  than  IBM  expected,  TCP/IP  has  been  established  as  a  long-term  option.  [Ref.  OSN 
1992] 

The  September  1992  issue  of  OSN:  The  Open  Systems  Newsletter  includes  various  expert 
viewpoints  on  the  TCP/IP  versus  OSI  debate. 

The  technical  body  that  oversees  the  development  of  the  Internet  suite  of  protocols  is 
termed  the  Internet  Architecture  Board  (IAB).  The  IAB  is  composed  of  senior  researchers,  the 
majority  of  whom  are  the  designers  and  original  implementors  of  the  Internet  suite.  Any  member 
of  the  Internet  community  can  design,  document,  implement,  and  test  a  protocol  for  use  in  the 
Internet  suite.  The  IAB  requires  that  protocols  be  documented  in  the  RFC  series. 

There  are  four  RFCs  that  define  the  status  of  documents  in  the  RFC  series.  The  first  is  the 
Assigned  Numbers  [Ref.  Reynolds  1987],  which  lists  the  assigned  values  used  for  the  parameters 
in  the  Internet  suite  of  protocols.  The  second  is  Official  Protocols,  which  lists  all  official 
protocols.  The  third  is  Gateway  Requirements,  which  lists  all  protocols  and  practices  that  relate  to 
network  nodes.  And  the  fourth  is  Host  Requirements,  which  lists  all  protocols  and  practices  that 
relate  to  host  nodes.  These  RFCs  are  periodically  updated,  with  the  most  recent  document  always 
taking  precedence.  A  list  of  RFCs  is  provided  in  Appendix  H. 

The  migration  from  the  TCP/IP  Internet  to  an  OSI/CLNP  internet  that  would  be  compliant 
with  US  GOSEP  (see  Section  16.1.3.1),  international  GOSIPs  (see  Sections  16.1.3  to  16.1.5), 
and  IGOSS  (see  Section  16.1.3.3)  is  not  well  defined  (see  Sections  9.13.8, 16.1.8,  and  19.1 1.2). 
Potentially  two  separate  Internets  could  exist  A  proposal  for  a  single  protocol  framework,  called 
Internet  2000,  has  been  developed  to  achieve  a  single  Worldwide  Internet  and  avoid  two  Internets. 
The  framework  is  a  descriptive  architecture  that  is  intended  to  lead  to  a  prescriptive  set  of 
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progressive  steps  and  interface  definitions  facilitating  “anything  over  anything”  interworking.  Key 
elements  of  the  proposed  framework  are  the  following:44 

•  Continue  current  practice  for  subnetworks.  TCP/IP  Internet  and  GOSIP  are  already 
compatible,  in  that  the  TCP/IP  Internet  does  not  specify  subnetwork  technologies  and 
GOSIP  recommends  a  specific  set  of  these  technologies. 

•  Continue  to  address  the  “large  flat  routing  table  problem”  in  the  TCP/IP  Internet  by 
those  approaches  that  would  achieve  a  worldwide  CLNP  Internet  “dialtone”  such  as 
TCP  over  CLNP  (TUBA)  and  Class  C  supemets  (classless  interdomain  routing, 
CIDR).  Further,  worldwide  internet  service  providers  should  provide  CLNP  Network 
Service  Access  Point  (NSAP)  addresses  in  a  new  Internet  worldwide  hierarchy  to 
facilitate  routing.  For  transition,  newer  TCP/IP  Internet  hosts  should  implement  TCP 
over  CLNP  in  addition  to  IP,  and  older  hosts  should  automatically  be  assigned  new 
Internet  NSAP  addresses  for  use  when  a  CLNP  capability  is  added.  Note:  CONS  is 
addressed  in  the  proposal  as  an  annex  in  that  it  is  a  feature  of  GOSIP,  EPHOS,  and 
IGOSS  but  not  viewed  as  a  main  issue  for  a  single  Internet  “dialtone.” 

•  Adopt  the  following  three  recommendations  for  Transport  services: 

The  TCP/IP  Internet  should  continue  to  provide  TCP  and  User  Datagram  Protocol 
(UDP,  equivalent  to  CLTP)  services  at  Sockets  and  Transport  Library  Interface 
(TLI)  interfaces  (de  facto  standard  APIs  to  the  Transport  service);  US  GOSIP 
should  continue  to  provide  the  OSI  CO  and  CL  transport  services  at  XU  (X/Open 
Transport  Interface — an  OSI  de  facto  standard  API  defined  by  X/Open)  interfaces 
using  TP4  and  CLTP;  and  the  X.500  Directory  should  be  used  to  identify  the  type 
of  Transport  protocol  entity  bound  to  each  NSAP  address. 

RFC  1006,  TCP/OSI  Coexistence  Stack  (i.e.,  TPO  over  TCP)  should  be  accepted 
and  extended  by  defining  all  the  ways  that  Application  services  from  either  suite 
may  call  upon  Transport  services  from  the  other  suite — “anything  over  anything 
interworking.” 

For  the  long  term  (but  before  2000),  both  communities  should  work  together  to 
develop  the  next-generation  Transport  protocol  using  rate-based  and  selective- 
retransmission  Transport  technology  that  will  be  needed  to  run  over  high-speed, 
mostly  reliable  networks  such  as  frame  relay,  SMDS  (connectionless  cell 
switching),  and  BISDN. 

•  Maintain  the  separate  methods  of  providing  Application  services  (direct  interface  in  the 
TCP/IP  Internet  for  FTP,  TELNET,  etc.;  and  use  of  Session,  Presentation,  and 
Application  Layers  in  OSI),  with  the  expectation  that  OSI  will  continue  to  look  into 
how  to  streamline  its  upper  layers  (e.g.,  a  fully  recursive  Upper  Layer  Architecture 
that,  like  the  Network  Layer,  is  basically  one  layer  with  a  specified  three-layer  internal 
organization,  together  with  use  of  the  “OSI  skinny  stack”).  Continue  work  on  new 
application  protocols.  The  1SO/ITU-TS  standardization  process  should  increasingly 
take  account  of  the  principles  and  methods  of  the  Internet  standardization  process.  To 
promote  application  portability,  both  communities  should  continue  to  support 
development  and  use  of  consortia-defined  OSEs,  APIs,  and  protocols. 

In  July  1992,  JTC1/SC6  agreed  to  offer  a  formal  liaison  to  the  IAB  to  encourage  future 
convergence  between  the  two  protocol  sets.  Two  factors  make  convergence  attractive  to  both 
groups.  The  Internet  expansion  in  the  market  has  shown  up  its  technical  weaknesses,  while  the 
technically  superior  ISO  protocols  still  lag  in  market  share.  If  successful,  the  convergence  would 
focus  work  on  a  single  approach,  saving  development  costs,  support  costs,  and  network  costs,  as 


44  The  GOSIP  Institute,  Internet  2000:  A  Protocol  Framework  to  Achieve  a  Single  Worldwide  TCP- 
IP/OSI/CLNP  Internet  by  Year  2000,  Version  2.2, 11  August  1992.  Provided  to  the  14-17  December  1992 
NIST-sponsored  OIW  meeting  on  OSE  in  Gaithersburg,  Maryland,  as  document  OSE-TC/92.051 . 
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well  as  allowing  more  diverse  portable  interworking  software.  [Ref.  OSN  1992n]  Further, 
[Ref.  SC21  N  7845  1993]  contains  the  Internet  Structure  and  Working  Group  Summary.  There  is 
also  a  proposal  for  SC21  to  establish  a  C-liaison  with  the  Internet  Society. 

9.7.5  Express  Transfer  Protocol  (XTP) 

The  Xpiess  Transfer  Protocol  (XTP)  combines  the  functionality  of  transport  and  internet 
protocols  to  produce  a  streamlined  protocol  that  requires  minimum  processing  and  allows  for 
parallel  processing  of  some  functions.  Two  types  of  packet  formats  are  used  in  XTP:  Information 
packet  and  Control  packet.  A  common  header  format  and  a  common  trailer  format  are  used  for 
both  packet  formats,  and  both  header  and  trailer  are  of  a  fixed  size  to  simplify  processing.  The 
individual  elements  of  the  XTP  packets  are  listed  below  [Stallings  1991,  pp.  609*612]: 

•  Route :  Provides  the  basis  for  packet  forwarding  through  an  internet  router.  The  value 
is  used  by  a  router  as  an  index  into  a  routing  table.  On  each  hop,  the  value  in  the 
router  field  is  changed  for  use  by  the  next  router. 

•  Time-to-live  (TTL):  Maximum  remaining  lifetime  of  the  packet  in  the  Internet, 
expressed  in  10-millisecond  clock  ticks. 

•  Key:  Logical  connection,  or  context,  identifier.  It  is  an  end-to-end  value  generated  at 
one  host  and  communicated  unchanged  through  internet  routers  to '  destination  host 
Each  side  of  a  connection  may  assign  its  own  key  value  to  the  conn,  ction.  Once  keys 
have  been  exchanged,  each  side  uses  the  key  of  the  other  side  in  transmissions. 

•  Sequence  (Seq):  The  32-bit  end-to-end  sequence  number  for  the  context  (connection). 

•  Rate:  Maximum  acceptable  transmission  rate  in  octets  per  second. 

•  Burst:  Maximum  number  of  octets  receiver  will  accept  per  burst  of  packets. 

•  Xkey:  Exchange  key.  Value  assigned  to  a  logical  connection  by  the  side  that  did  not 
originate  the  connection;  the  value  is  returned  to  the  other  side  for  future  use. 

•  Xroute:  Exchange  route.  Functions  in  manner  similar  to  Xkey,  for  internet  routers.  In 
this  case,  the  exchange  is  done  on  a  hop-by-hop  basis,  rather  than  end-to-end. 

•  Alloc:  Other  side  may  send  octets  up  to  but  not  including  this  sequence  number. 

•  Rseq:  Sequence  number  expected  on  next  incoming  packet;  once  past  the  highest 
consecutive  sequence  number  received  without  error. 

•  Nspan:  Number  of  pairs  in  spans  array. 

•  Spans:  Up  to  16  pairs  of  sequence  numbers.  Each  sequence  number  pair  identifies  a 
span  of  packets  that  has  been  successfully  received.  This  selective  acknowledgment 
identifies  gaps  of  packets  that  must  be  retransmitted. 

9.7.6  Integrated  Services  Digital  Network 

ISDN  is  the  result  of  the  current  evolution  of  the  networks  and  services  available  from  the 
various  PTTs  (Post,  Telephone,  and  Telegraph).  The  original  telephone  or  telegraph  networks 
(PSTNs,  Public  Switched  Telephone  Networks)  were  based  on  analog  equipment  Tn  recent 
years,  analog  equipment  has  been  replaced  with  digital  equipment.  This  ha*  lead  to  the 
replacement  of  analog  PSTN  with  digital  IDNs  (Integrated  Digital  Networks).  IDN  incorporates 
the  latest  in  digital  switching  and  transmission.  The  extension  of  IDN  to  provide  additional  user 
services  has  resulted  in  ISDN. 

ISDN  makes  an  all-digital  interface  available  to  the  network  subscriber.  This  system 
features  a  high  data  or  bit  rate,  digital  transmission,  and  digital  switching.  Digital  switching 
provides  a  fast  connect  or  call  setup  for  voice  and  data  communications.  An  ISDN  node  can 
connect  to  packet  based  and  circuit  based  networks,  which  can  be  switched  or  nons witched.  The 
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ISDN  provides  a  digital  interface  to  the  user.  This  allows  the  user  to  "directly"  connect  digital 
devices  to  the  network.  The  following  types  of  communications  channels  are  used  to  construct 
various  transmission  structures  (“pipes”): 

•  B-channel,  64  kbps — the  basic  user  channel  for  digital  data,  digitized  voice,  and  other 
“mixed”  traffic. 

•  D-channel,  16  or  64  kbps — used  to  carry  signalling  information  and  to  set  up  calls  on 
the  B -channels  at  the  customer’s  interface.  The  three  types  of  traffic  (see  below)  share 
the  D-channel  by  means  of  statistical  multiplexing. 

•  HO-channel,  384  kbps. 

•  HI  1-channel,  1.536  Mbps. 

•  H12-channel,  1.92  Mbps. 

Basic  access  (2B+D)  consists  of  two  full-duplex  64-kbps  B-channels  and  a  full-duplex 
16-kbps  D-channel;  this  144-kbps  information  rate  has  overhead  for  framing,  synchronization,  and 
other  requirements  that  bring  the  total  bit  rate  to  192  kbps.  Reduced  variants  of  basic  access  are 
B+D  and  D  alone.  Primary  access  (used  for  switchboards  and  LANs)  differs  for  various 
countries:  1.544  Mbps  (the  T-l  transmission  facility  of  AT&T)  in  the  United  States  (typically 
23  B-channels  plus  one  64-kbps  D-channel);  2.048  Mbps  in  Europe  (typically  30  B-channels  plus 
one  64-kbps  D-channel).  Primary  rate  interfaces  using  H-channels  include:  3H0+D 
(1.544  Mbps);  4H0  (1.544  Mbps);  5H0+D  (2.048  Mbps);  1H1  (1.536  kbps);  H12+D 
(1.920  Mbps);  3HO+5B+D  (1.544  Mbps);  and  3H0+6B  (1.544  Mbps). 

The  protocols,  services,  and  interfaces  to  an  ISDN  network  are  defined  or  specified  in  the 
ITU-TS I  Series  recommendations  (see  end  of  Appendix  E).  ITU-TS  SG  XVIII  is  the  primary 
ISDN  committee  (the  ANSI  counterpart  is  the  T1S1  committee). 

The  ISDN  protocol  architecture  is  shown  in  Figure  12,  together  with  the  relation  of  these 
protocols  to  the  ISO  seven-layer  model.  ISDN  is  essentially  unconcerned  with  Layers  4 
through  7.  LAPD  is  based  on  HDLC  with  modifications  to  meet  ISDN  requirements  for  control 
signaling,  packet  switching,  and  telemetry.  A  link-layer  protocol,  call  control  (1.451),  supports 
control  signalling  by  establishing,  maintaining,  and  terminating  connections.  For  packet 
switching,  X.25  packets  are  transmitted  in  LAPB  frames  and  the  X.25  Packet  Level  Protocol 
establishes  virtual  circuits  on  the  D-channel  to  other  users  and  to  exchange  packetized  data.  The 
B-channel  can  be  used  for  circuit  switching,  semipermanent  circuits,  and  packet  switching.  In 
circuit  switching,  a  circuit  is  set  up  on  a  B-channel  on  demand,  using  the  D-channel  call  control 
protocol.  Semipermanent  circuits  are  set  up  using  the  B-channel  by  prior  agreement;  as  with 
circuit-switched  connection,  the  semipermanent  circuit  (equivalent  to  a  leased  line)  provides  a 
transparent,  full-duplex  data  path  between  end  systems.  Frame  relay  (see  Section  9.6.4)  can  be 
used  on  the  B-channel  (as  well  as  over  H-channels). 

Teleservices  employ  the  B-channel  for  user  information  and  D-channel  for  signalling 
information.  Teleservices  include  telephony  (3.1  kHz  speech);  teletex  (F.200;  end-to-end  text 
communications  using  standardized  character  sets,  presentation  formats,  and  communications 
protocols);  telefax  (Facsimile  Group  4  ITU-TS  Recommendation;  end-to-end  facsimile 
communication  using  standardized  picture  coding,  resolution,  and  communications  protocols); 
mixed  mode  (text  and  facsimile  for  end-to-end  transfer  of  documents  containing  text  and  fixed 
images);  videotext  (provides  retrieval  and  mailbox  functions  for  text  and  graphic  information);  and 
telex  (interactive  text  communication). 
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Hie  ISDN  protocols  address  several  requirements  outside  the  OSI  architecture.  Examples 
are  the  following: 

•  Multiple  related  protocols,  such  as  the  use  of  a  protocol  on  the  D-channel  to  set  up, 
maintain,  and  terminate  a  connection  on  die  B -channel 

•  Multimedia  calls,  allowing  a  call  to  be  set  up  that  permits  information  flow  consisting 
of  multiple  types,  such  as  voice,  data,  facsimile,  and  control  signals 

•  Multipoint  connections,  such  as  conference  calls. 
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Figure  12.  ISDN  Protocol  Architecture 

ITU-TS  Recommendation  1.430  specifies  the  physical  interface  to  an  ISDN  network.  It 
describes  the  bit,  octet,  and  channel  synchronization,  as  well  as  the  D-channel  and  access  control. 
Recommendation  ITU-TS  L440  describes  the  data  link  logical  connection  via  the  D-channeL  This 
includes  die  ability  to  transfer  a  packet  via  the  D-channeL  This  recommendation  also  indicates  how 
to  establish  and  clear  a  call  through  a  circuit  switched  or  packet  switched  network.  ITU-TS  1.440 
and  ITU-TS  L441  collectively  provide  the  service  and  protocol  definitions  and  specifications  for  an 
ISDN  network. 

Recommendations  ITU-TS  1.450  and  ITU-TS  1.451  describe  how  to  establish  a  network 
connection  in  a  circuit  or  packet  switched  network.  They  describe  die  protocols  for  the  transfer  of 
a  data  packet  or  datagram  over  a  connectionless  network.  They  also  describe  how  to  perform  the 
same  task  using  a  virtual  circuit  in  a  connection  oriented  network.  To  allow  satellite  ISDN 
connection,  work  has  been  undertaken  to  help  ensure  compatibility  between  ITU-TS  ISDN 
recommendations  and  satellite  link  parameters  [SC21 N  5572,  January  1991]. 

One  of  the  questions  for  the  next  (1993-1996)  study  period  proposed  by  ITU-TS  SGVII 
has  to  do  with  the  requirements,  arrangements,  and  interface  characteristics  for  the  provision  of 
data  services  in  PSDNs  when  accessed  via  ISDNs  and  in  ISDNs.  [Ref.  SC21  N  6956  1992] 
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To  further  promote  ISDN  compatibility  and  define  specific  services,  a  North  American 
(NA)  ISDN  User's  (NIU)  Forum  has  been  created  with  sponsorship  of  the  NIST.  It  has  three 
objectives: 

•  Provide  a  forum  for  users  to  influence  the  developing  ISDN  to  reflect  their  needs 

•  Identify  ISDN  applications  and  develop  implementation  requirements  for  those 
applications  to  facilitate  timely  and  interoperable  multi-vendor  implementations 

•  Solicit  user  and  product  participation  in  this  process. 

The  NIU  Forum  consists  of  two  workshops:  the  ISDN  User's  Workshop  (IUW)  and  the 
ISDN  Implementor's  Workshop  (IIW).  The  IUW  produces  applications  requirements  that 
describe  potential  applications  of  ISDN  and  their  requirements.  The  IIW  then  develops 
applications  profiles,  implementation  agreements,  and  conformance  criteria  that  allow  interoperable 
implementations  of  solutions  to  the  applications  requirements.  [Ref.  Burr  1991] 

ISDN  use  varies  greatly  in  Europe  from  nonexistence  in  some  countries  to  thousands  of 
lines  in  France  and  Germany.  The  European  Commission  has  been  actively  urging  European 
Community  members  to  implement  ISDN  services  with  the  goal  that  by  1994  all  member  countries 
will  offer  commercial  ISDN.  Some  progress  is  being  made  toward  standardized  interconnection 
between  different  countries'  ISDN  services.  The  first  phase  of  the  European  Telecommunications 
Standards  Institute  (ETSI)  calls  for  all  countries'  ISDN  services  to  be  connected  by  December 
1993;  however,  to  date,  a  standard  has  not  been  developed  for  such  interconnections.  [Ref. 
Computerworid  1991] 

According  to  a  recent  NIST  report  on  ISDN  security  [Ref.  Burr  1991],  ISDN  has  been 
developed  with  little  thought  to  security.  The  document  recommends  extending  the  five  security 
services  defined  in  ISO  749S-2  to  all  ISDN  applications,  including  voice  use  of  the  public 
network.  It  contends  that  a  standard  for  the  reliable  authentication  of  human  users  is  badly  needed 
for  ISDN  security. 

The  following  ETSI  profiles  specify  ISDN-specific  protocols  (rather  than  using  existing 
transport  and  relay  profiles  for  ISDN  and  the  FT AM  application  profile  ISP  10607);  when 
complete,  they  will  be  mandatory  for  nations  of  the  European  Commission: 

•  prETS  300  075,  FT AM  over  ISDN  (based  on  Videotex) 

•  prETS  300  383,  File  Transfer  over  ISDN  EUROFILE  Transfer  Profile,  December 
1993  (EUROFTLE  is  an  ISDN  telematic  service  in  which  end-to-end  compatibility 
between  terminals  is  guaranteed  and  which  supports  file  exchanges  between  different 
types  of  equipment;  files  are  exchange  over  one  B -channel  at  the  rate  of  64  kbps) 

•  prETS  300  388,  FT AM  over  ISDN  Using  Simple  File  Transfer  Standard,  December 
1993,  ETSI. 

9.8  Transport  Layer  Standards 

ISO  7498  characterizes  the  Transport  Layer  as  providing  transparent  transfer  of  data 
between  session  entities.  It  relieves  session  entities  from  any  concern  with  the  detailed  way  in 
which  reliable  and  cost-effective  data  transfer  is  achieved.  All  protocols  at  this  layer  have  end-to- 
end  significance  between  transport  entities  in  end  systems.  [Ref.  Stallings  1993,  p.  175]  The 
Transport  Layer  standards  are  listed  in  Table  21. 

The  services  provided  by  the  Transport  Layer  can  be  either  in  connectionless  or  connection- 
oriented  modes.  ISO  has  identified  five  classes  of  transport  protocols.  During  connection 
establishment,  transport  entities  negotiate  which  transport  protocol  to  use  based  on  the  QoS 
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parameter  requested  by  the  calling  transport  service  user.  This  allows  implementations  of  more 
sophisticated  transport  protocols  to  provide  a  superior  service  to  their  users  while  retaining 
interoperation  with  simpler  implementations.  [Ref.  Tang  1992,  pp.  29-30] 


Table  21.  Transport  Layer  Standards 


ISO  8072 
ADI 

ISO  8073 
ISO  8602 
ISCVIEC  TR 10023 

ISCVIEC  TR 10172 
POTR 10734 
ISCVIEC  TR  10735 
ISCVIEC  10736 
PDAM1 
ISCVIEC  10737 

ISCVIEC  10740-1 
ISCVIEC  10740-2 
ISCVIEC  11570 
ITU-TST.70 
ITU-TS  X214 
mi-TS  X.224 


Transport  Servics  Definition 
Conneetionlms-Mode  Tranamiaaion 

Cormaction-Oriantad  Transport  Protocol  Specification,  Ravtaion 
Protocol  for  Providing  tha  Connect  ion  laaa -Mode  Transport  Sarvica 
A  Formal  Daacription  of  ISO  8072  in  LOTOS  (awaiting  daciaion  concerning  further 
progreaaion) 

NatworWTransport  Protocol  Interworking  Specification 
Guidalinaa  for  Bridged  LAN  Source  Routing  Operation  by  End  Systems 
Standard  Group  MAC  Addresses 
Transport  Layer  Security  Protocol 
Security  Association  Establishment  Protocol 
Specification  of  Elements  of  Management  Information  Related  to  OSI  Transport  Layer 
Standards 

Text  and  Office  Systems  -  Referenced  Data  Transfer,  Part  1:  Abstract  Service  Definition 
Text  and  Office  Systems  -  Referenced  Data  Transfer,  Part  2:  Protocol  Specification 
Transport  Protocol  Identification  Mechanism 

Network-Independent  Basic  Transport  Sendee  for  the  Telematic  Services 
Transport  Service  Definition  for  OSI  for  CCITT  Applications 
Transport  Protocol  Specification  for  OSI  for  CCITT  Applications 


The  definitions  of  five  transport  protocol  classes  depend  on  the  types  of  network  service. 
ISO  identifies  three  types  of  network  services  [Ref.  Tang  1992]: 

•  Type  A  network  service  is  essentially  perfect  The  fraction  of  die  packets  that  are  lost 
duplicated,  or  garbled  is  negligible.  Resets  are  used  so  rarely  that  they  can  be  ignored. 
A  point-to-point  network  is  an  example  of  a  Type- A  network. 

•  Type  B  network  service  provides  network  connections  with  an  acceptable  residual 
error  rate  but  an  unacceptable  signalled  failure  rate.  Residual  errors  are  those  that  are 
not  corrected,  and  for  which  transport  service  provider  is  not  notified.  On  the  other 
hand,  a  signalled  failure  is  a  failure  detected  by  the  Network  Layer  which  then  signals 
die  transport  entities  for  recovery. 

•  Type  C  network  service  is  not  reliable  enough  to  be  trusted  at  all  (e.g.,  the  residual 
error  rate  is  unacceptable).  These  networks  do  not  detect  errors  if  data  are  lost, 
duplicated,  re-ordered  or  corrupted.  Transport  protocols  that  must  live  with  Class  C 
network  services  are  most  complex  of  all.  A  satellite  network  and  an  interconnection 
of  LANs  and  WANs  are  examples  of  a  Type  C  network. 

The  five  classes  of  connection-mode  transport  protocol,  defined  by  ISO  8073,  are  based  on 
the  three  kinds  of  network  services  noted  above  [Ref.  Stallings  1993].  The  transport  protocol 
classes  are  the  following: 

•  Class  0  Simple  class,  oriented  for  Teletex  (upgrade  to  ITU-TS  T.70).  Connection 
flow  control  is  based  on  network  flow  control,  and  connection  release  is  based  on 
release  of  the  network  connection. 

•  Class  i  Basic  error  recovery  class,  designed  to  run  on  a  ITU-TS  X.25  network  and 
provide  minimal  error  recovery  for  network-signalled  errors.  TPDUs  are  numbered  so 
that  they  can  be  resequenced. 
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•  Class  2.  Multiplexing  class,  an  enhancement  of  Class  0  that  still  assumes  a  highly 
reliable  network  service.  Has  the  ability  to  multiplex  multiple  transport  connections 
onto  a  single  network  connection. 

•  Class  3.  Error  recovery  and  multiplexing  class.  Provides  the  union  of  the 
capabilities  of  Class  1  and  Class  2. 

•  Class  4.  Error  detection  and  recovery  class.  Assumes  that  the  underlying  network 
service  is  unreliable,  in  particular  that  the  TPDUs  may  be  lost  or  arrive  out  of 
sequence.  Provides  for  TPDU  retransmission,  duplicate  detection,  flow  control, 
connection  establishment  and  termination,  and  crash  recovery. 

9.9  Session  Layer  Standards 

The  Upper  Layers  of  the  OSI  Reference  Model  are  Layers  5-7:  Session,  Presentation,  and 
Application  Layers  are  handled  within  ISCVIEC  by  SC21.  Standards  in  the  Application  Layer 
define  procedures  for  the  support  of  distributed  information  processing.  The  Application  Layer 
differs  from  the  other  layers  of  OSI  in  several  respects.  Entities  in  the  Application  Layer  ate  made 
up  of  a  collection  of  application  service  elements  (ASEs),  each  of  which  is  defined  by  a  set  of 
service  and  protocol  standards.  These  ASEs  are  combined  in  various  ways  to  form  several  types 
of  Application  Elements  (AEs).  The  Presentation  Layer  supports  the  Application  Layer  by 
providing  facilities  for  representing  information  exchanged  between  AEs.  The  Session  Layer 
provides  the  mechanisms  that  may  be  used  for  controlling  interactions  between  AEs.  Standards  for 
the  Session  Layer  are  given  in  Table  22. 

Table  22.  Session  Layer  Standards 


iS6  8326  6onnectlon-&ientod  Session  Service  Definition  (X21 5) 

AM  4  Additions!  Synchronization  Functionality 

WDAM5  Removal  of  Session  Layer  Serial  Number  Limitation 
DiS  8326.2  Connection  Oriented  Session  Service  DsHnMon,  EdWon  2  QC21S) 

ISO  8327-1  Basic  Connection-Oriented  Session  Protocol  Part  1:  Protocol  Specification 

ISO  8327  Basic  Connection-Oriented  Session  Protocol  SpecVication  (X22S) 

AM  3  Incorporate  Additional  Synchronization  Functionality 

WDAM  4  Removal  of  Session  Layer  Serial  Number  Limitation 
DIS  8327-1  Basic  Connection-Oriented  Session  Protocol,  Part  1:  Protocol  Specification.  Edrtion  2  of 

ISO  8327  (X225) 

ISO  8327-2  Basic  Connectjon-Oriented  Session  Protocot  Part  Z.  PICS  Proforma  ()C245) 

ISO  9548  Session  Connectionless  Protocol  to  Provide  Connect  ion  less -Mode  Session  Service  (X.235) 
ISQflEC  9548-2  Session  Connectionless  Protocol  to  Provide  Connectionless-Mods  Session  Service,  Part  2: 
PICS  Preforms  (X255) 

DIS  10168-1  Conformance  Test  Suits  for  the  Session  Protocol,  Part  1:  Test  Suite  Structure  and  Teel 
Purposes 

CD  10168-2  Conformance  Test  Suits  for  the  Session  Protocol,  Part  2:  Common  Session  Abstract  Teat 
Suits 

CD  10168-3  Conformance  Test  Suits  lor  the  Session  Protocol,  Pert  3:  Abstract  Teat  Suita  for  the  CS 
Method 

DIS  10168-4  Conformance  Teat  Suita  forth#  Session  Protocol,  Part  4:  Session  Teat  Management  Protocol 
Specification 

(TU-TS  X.215  Session  Service  Definition  for  OSI  for  CCfTT  Appficatione 
(TU-TS  X.225  Session  Protocol  Specification  for  OSI  for  CCITT  AppScation 
ITU-TS  X235  Connectionless  Session  Protocol  (ISO  9548) 

(TU-TS  X.245  Session  PICS  Proforma  (ISO  8327-2) 

ITU-TS  X.2S5  Conmseaonisss  Session  PICS  Proforma  (ISOflEC  9548-2) _ 
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The  primary  purposes  of  the  session  service  are  to  organize  a  session  dialogue  and  to 
mange  the  data  exchange  between  two  communicating  session  service  users.  These  purposes  are 
accomplished  as  follows  [Ref.  Tang  1992]: 

•  To  organize  a  session  dialogue,  the  Session  Layer  adds  structure  to  a  transport  pipe. 
A  session  connection  can  be  structured  into  activities  representing  different  logical 
pieces  of  work.  An  activity  can  be  structured  further  into  dialogue  units.  With  the  use 
of  this  structure,  the  Session  Layer  provides  service  elements  for  activity  management 
and  dialogue  control.  The  dialogue  control  facilities  allow  a  session  service  user  to 
insert  either  major  synchronization  points,  which  separate  dialogue  units,  or  minor 
synchronization  points,  which  can  appear  anywhere  within  a  dialogue  unit.  A 
resynchronization  service  is  also  provided  to  assist  orderly  re-establishment  of 
communication. 

•  To  manage  the  data  exchange,  the  session  service  provides  four  kinds  of  data  transfer 
facilities: 

Normal  data  transfer  facility,  which  can  operate  in  either  full-duplex  or  half¬ 
duplex  mode  and  for  which  only  the  owner  of  the  data  token  can  send  data 
Expedited  data  transfer  facility 

Typed  data  transfer  facility,  which  allows  a  session  service  user  to  send  data 
outside  the  normal  data  stream  independent  of  the  availability  and  the  assignment 
of  the  data  token 

Capability  data  transfer  facility,  which  allows  session  service  users  to  exchange 
limited  amounts  of  user  data  while  not  within  an  activity. 

In  a  liaison  statement  to  SC21/WG6,  ITU-TS  SGVII  stated  that  the  concepts  of  "dependent 
conformance"  and  "general  conformance"  are  not  sufficiently  defined  to  be  used  in  the  Session 
PICS  (ISO  8327-2)  now.  [Ref.  SC21  N  6905  1992) 

The  ITU-TS  Session  Layer  telematic  recommendations  are: 

•  T.5,  General  Aspects  of  Group  4  Facsimile  Apparatus 

•  T.62,  Control  Procedures  for  Teletex  and  Group  4  Facsimile  Services 

•  X.3,  Packet  Assembly/Disassembly  Facility  ( PAD)  in  a  Public  Data  Network  ( PDN) 

•  X.20,  Interface  Between  DTE  and  DCE  for  Start-Stop  Transmission  Services  on 
Public  Data  Networks 

•  X.28,  DTEJDCE  Interface  for  a  Start/Stop  Mode  DTE  Accessing  die  PAD  in  a  PDN 
Situated  in  the  Same  Directory  (Country) 

•  X.29,  Procedures  for  the  Exchange  of  Control  Information  and  User  Data  Between  a 
PAD  and  a  Packet  Mode  DTE  or  Another  PAD. 

Conformance  Testing  standards  for  the  Session  Layer  include  [Ref.  SC21  N  8081  1993]: 

•  DIS  10168-1,  Conformance  Test  Suite  for  the  Session  Protocol  -  Part  1:  Test  Suite 
Structure  and  Test  Purposes ,  April  1990  (expected  to  reach  IS  status  by  end  of  1994) 

•  CD  10168-2,  Part  2:  Common  Session  Abstract  Test  Suite  (replaces  the  former 
CD  10168-2,  Generic  Test  Suite,  March  1992,  which  was  cancelled  since  ISO  9646 
no  longer  recognizes  generic  test  suites) 

•  CD  10168-3,  Part  3:  Abstract  Test  Suite  for  the  CD  Method,  September  1993 
[SC21  N  8164]  (replaces  Generic  Test  Suite,  March  1992,  which  was  cancelled  since 
ISO  9646  no  longer  recognizes  generic  test  suites) 

•  DIS  10168-4,  Part  4:  Session  Test  Management  Protocol  Specification,  March  1991 
(expected  to  reach  IS  status  by  end  of  1994). 
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9.10  Presentation  Layer  Standards 

The  Presentation  Layer  provides  two  types  of  service,  one  to  handle  the  representation  of 
information  exchanged  between  two  communicating  application  entities  so  that  the  types  and  values 
of  the  information  exchanged  will  be  preserved,  and  another  that  is  session  related  (required  by  the 
OSI  architecture  for  session-related  requests).  General  Presentation  Layer  standards  are  given  in 
Table  23. 

The  Presentation  Rapporteur  Group  is  requesting  comments  from  National  Bodies 
regarding  the  merits  of  adding  support  for  compression  of  protocol  data  units  (PDUs)  within  the 
presentation  protocol.  Options  could  include  compression  of  the  complete  presentation  PDU, 
compression  of  the  complete  user  data  parameter  of  the  presentation  PDU,  or  a  selectable 
transformation  to  be  applied  to  the  encoding  of  an  individual  presentation  data  value.  [Ref. 
SC21  N  6985  1992] 

The  telematic  services  for  the  Presentation  Layer  are  defined  by  the  following  ITU-T'S 
recommendations: 

•  T.6,  Facsimile  (FAX)  Coding  Schemes  and  Coding  Control  Functions  for  Group  4 
Facsimile  Apparatus 

•  T.51,  Coded  Character  Sets  far  Telematic  Services 

•  T.61,  Character  Repertoire  and  Coded  Character  Sets  far  the  International  Teletex 
Service 

•  T.73,  Document  Interchange  Protocol  far  die  Telematic  Services. 

9.10.1  Abstract  Syntax  Notation  One  (ASN.l) 

Application  entities  need  to  know  the  structure  and  content  of  application  protocol  data 
units,  but  not  their  representation.  Agreeing  on  a  common  representation  is  a  responsibility  of  the 
Presentation  Layer.  An  abstract  syntax  language  is  used  to  describe  the  structure  and  content  of  a 
structured  object  Encoding  rules  specify  a  representation  for  the  physical  data  exchange. 
[Ref.  Tang  1992] 

At  present  ASN.l  is  the  only  abstract  syntax  language  that  exists  in  OSI.  Abstract  syntax 
languages  describe  data  types  in  a  machine-independent  manner,  thus  freeing  data  representation 
from  machine  restrictions.  For  example,  a  protocol  specifying  that  a  data  type  is  an  integer  need 
not  concern  itself  with  the  number  of  bits  required  for  the  internal  machine-dependent 
representation  of  this  data  type. 

ASN.l  has  a  rich  syntax  for  describing  data  types  and  provides  a  macro  facility  for 
extending  its  grammar.  According  to  Rose  [Ref.  Rose  1990], 

ASN.l  is  destined  to  become  die  network  programming  language  of  the  90s,  just  as 

the  C  programming  language  is  largely  seen  as  having  been  the  systems 

programming  language  of  die  80s. 

The  pertinent  specifications  (December  1987,  Revised  April  1990)  for  ASN.l  are  ISO  8824, 
ISO  8824/ ADI  (incorporated  into  ISO  8824),  ISO  8824/DAM  2,  ISO  8824/PD  AM  3.2.  and 
recommendation  X.208  from  ITU-TS.  The  ISO  specifications  are  compatible  with  those  of  ITU- 
TS,  but  include  a  few  extensions.  [Ref.  Stallings  1987] 


Chapter  9 


174 

UNCLASSIFIED 


Network  Service  Standards 


UNCLASSIFIED 


Tabl*  23.  General  Presentation  Layer  Standard* 


&&S822  “ 

Connection-Oriented  Presentation  Service  Definition  (X-218) 

AMI 

Connectionlees-Mode  Presentation  Sorvieo 

AM  2 

UnMmited  User  Data 

DM43 

Abstract  Syntax  Registration 

AM4 

Support  of  Session  Symmetric  Synchronization  Service 

AMS 

Delivery  of  Additional  Session  Synchronization  Functionality  to  the  Presentation  Service 

User 

DIS  88223 

Basic  Presentation  Service  Definition,  Edition  2 

ISO  8823 

Connection-Orient sd  Presentation  Protocol  Specification  (X.226) 

AM2 

Unfimked  User  Data 

DAM3 

Transfer  Syntax  Registration 

AM4 

Support  of  Session  Symmetric  Synchronization  Service 

AMS 

Additional  Synchronization  Functionality  to  the  Presentation  User 

DIS  8823-1 

Connection  Oriented  Presentation  Protocol,  Part  1:  Protocol  Specification,  Edition  2  of 
ISO  8823 

ISOIEC  8823-2 

Connection-Oriented  Presentation  Protocol  Specification,  Part  2:  Presentation  Protocol 
Implementation  Conformance  Statement  (PICS)  Proforma  (X246) 

(SO  9676  • 

Presentation  Connectionless  Protocol  to  Provide  Connectionless-Mode  Presentation 
Service  (X236) 

DIS  9578-2 

Presentation  Protocol  to  Provide  the  Connectionless-Mode  Presentation  Service,  Part  2: 
PICS  Proforma  for  Connectionless  Presentation  Protocol  (X356) 

ISOIEC  10729-1 

Conformance  Test  Suita  for  the  Presentation  Protocol.  Part  1:  Test  Suite  Structure  and  Test 
Purpoees 

DIS  10729-2 

Conformance  Test  Suite  for  the  Presentation  Protocol,  Part  2:  Teat  Suite  for  ASN.1 
Encorfings  and  Test  Purposes  for  Presentation  Protocol 

WO  10729-3 

Conformance  Test  Suite  for  the  Presentation  Layer,  Part  3:  Common  Presentation  Abetrect 
Teat  Suite 

ITU-TSX218 

Presentation  Service  Definition  for  OSI  for  CCTTT  Applications 

ITU-TSX228 

Presentation  Protocol  Specification  for  OSI  for  CCfTT  Application 

ITU-TSX336 

Connectionless  presentation  protocol  (ISO  9576) 

ITU-TSX248 

Presentation  PICS  Proforma,  (ISO  8823-2) 

ITU-TSX2S6 

Connectionless  Presentation  PICS  Proforma.  (ISO  9578-2) 

ASN.l  standards  are  listed  in  Table  24.  Hie  table  shows  that  the  current  ISO  8824  is  being 
revised  as  Part  1  of  a  four-part  standard  arranged  as  follows: 

•  Part  1 :  Basic  Notation 

•  Part  2:  Information  Object  Specification  — provides  notation  that  allows  information 
object  classes  as  well  as  individual  information  objects  and  sets  thereof  to  be  defined 
and  given  reference  names. 

•  Part  3:  Constraint  Specification — describes  how  the  notation  can  be  defined  that 
further  constrains  the  values  that  can  appear  in  the  notation  of  Parts  1  and  2,  which 
define  a  structured  data  type  to  convey  their  semantics. 

•  Part  4:  Parameterization  of  ASN.l  Specifications— describes  how  specifications  may 
leave  certain  aspects  (e.g.,  bounds)  undefined  at  die  time  of  abstract  syntax  definition, 
being  completed  by  the  specification  of  ISPs  for  functional  profiles  from  some  other 
body.  The  requirements  not  met  by  Parts  2  and  3  are  met  in  Part  4  by  die  provision 
for  parameterized  reference  names  and  parameterized  assignments  by  this  part  of  the 
ASN.l  specification. 

ASN.l  Information  Objects,  Constraints,  Parameterization  -  Tutorial  and  Worked 
Examples ,  Version  2,  May  1991,.provides  a  tutorial  and  collection  of  worked  examples  related  to 
the  proposed  ASN.l  extensions  in  the  area  of  macro  replacement  Its  aim  is  to  support  the  early 
adoption  of  these  extensions  by  current  macro  users.  [Ref.  SC21 WG6  N 1 171  1992] 
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Table  24.  Presentation  Layer  ASN.1  Standards 


IS0/IE6  8824  Specification  of  Abstract  Syntax  Notation  One  (ASN.1 )  (X208)  ~ 

DAM  2  Amendments  to  ISO  8824  to  Give  ISO  8824  Part  1:  Specilication  of  Basic  Notation 

WDAM4  Removal  of  Definition  of  Root  Arcs  of  Object  Identifier  Tree 
ISO/IEC  8824-1  Specification  of  Abstract  Syntax  Notation  One  (ASN.1),  Part  1:  Specification  of  Basic 
Notation  (X680) 

PDAM  3.2  Rules  of  Extensfcility 

ISO/IEC  8824-2  Specification  of  Abstract  Syntax  Notation  One  (ASN.1),  Part  2:  Information  Object 
Specification  (X.681) 

ISO/IEC  8824-3  Specif  teal  ion  of  Abstract  Syntax  Notation  One  (ASN.1),  Part  3:  Constraint  Specification 

(X.682) 

ISO/IEC  8824-4  Specification  of  Abstract  Syntax  Notation  One  (ASN.1),  Part  4:  Parameterization  of  ASN.1 
Specifications  (X683) 

ISO/IEC  8825  Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1 )  (X 209) 

DAM2  Amendments  to  ISO  8825  to  Give  ISO  8825  Part  1:  Basic  Encoding  Rules 

AM  3  Rules  for  Extensibility 

DIS  8825-1  Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1),  Part  1: 

Basic  Encoding  Rules  (BER)  (X.690) 

WDAM1  Light  Weight  Encoding  Rules  for  ASN.1 

DIS  8825-2.2  Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1),  Part  2: 
Packed  Encoding  Rulea  (PER) 

DfS  8825-3  Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1).  Part  3: 

Distinguished  and  Canonical  Encoding  Rules  (X.692) 

DIS  8825-4  Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1),  Part  4: 

Test  Suite  Structure  and  Test  Purposes  for  ASN.1  Encodings 
SC21N6130  Working  Draft  for  ASN.1  Encoding  Rules  to  Provide  Upper  Layer  Security  and  Compression 
ITU-TS  X208  Specification  of  Abstract  Syntax  Notation  One  (ASN.1) 

ITU-T5  X.20S  Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1) 

ITU-TS  X.680  ASN.1  Specification.  Basic  ASN.1  (ISO  8824-1) 

ITU-TS  X.681  ASN.1  Specification,  Information  Object  Specification  (ISO  8824-2) 

ITU-TS  X.682  ASN.1  Specification.  Constraint  Specification  (ISO  8824-3) 

ITU-TS  X.683  ASN.1  Specification,  Parameterization  (ISO  8824-4) 

ITU-TS  X.680  ASN.1  Specification,  Basic  Encoding  Rules  (ISO  8825-1) 

ITU-TS  X692  ASN.1  Specification.  Distlnguished'Canonical  Rules  (ISO  8825-3) 


Material  on  an  Abstract  Syntax  Model  [SC21  N  6133,  December  1991]  was  removed  from 
the  ASN.1  Enhancements  as  being  too  immature  at  this  stage.  However,  it  is  believed  that  the 
topic  requires  further  consideration.  Other  topics  that  require  further  consideration  include  ASN.1 
compatibility  issues  [SC21  N  6134,  January  1992]  and  application  indexes  [SC21  N  6135, 
January  1992]. 

The  Framework  for  the  Support  of  Distributed  Applications  (DAF),  a  new  activity 
established  by  ITU-TS  SG  VII  to  standardize  common  aspects  of  distributed  applications,  has  been 
working  for  various  enhancements  to  ASN.1  with  the  following  goals  [Ref.  OSN  1990f): 

•  Provide  a  firmer  framework  for  the  specification  of  table  types  and  functions 

•  Improve  current  definitions  of  character  strings 

•  Provide  new  encoding  rules — Packed  Encoding  Rules  (PER),  Confidential  Encoding 
Rules  (CER),  Lightweight  Encoding  Rules  (LWER),  and  Distinguished  Encoding 
Rules  (DER)— to  supplement  or  replace  the  current  Basic  Encoding  Rules  (BER) 

•  Improve  machine  processability 

•  Provide  miscellaneous  enhancements. 

SC24/WG1  is  developing  an  Image  Processing  and  Interchange  (IPI)  Standard  (see  Section 
1.2.2 A)  that  is  noted  in  ASN.1;  however,  several  questions  have  arisen  requiring  liaison  with 
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SC21/WG6.  One  important  issue  is  the  apparent  inefficiency  of  representing  large  arrays  that  are 
fundamental  to  the  expression  of  image  data.  [Ref.  SC24  N  744  1992] 

9.10.2  ASN.l  Encodings 

The  mechanism  that  translates  the  abstract  representation  of  data  to  its  physical 
characteristics,  either  for  machine  storage  or  for  transmittal,  is  called  transfer  syntax.  The  transfer 
syntax  in  OSI  corresponding  to  the  abstract  syntax  ASN.l  is  contained  in  Basic  Encoding  Rules, 
ISO  8825.  The  relevant  standards  for  BER  are  ISO  8825,  ISO  8825/ADI,  ISO  8825/AD2,  and 
ITU-TS  X.209.  Again,  the  ISO  and  the  ITU-TS  specifications  are  compatible. 

Additional  sets  of  encoding  rules  are  being  incorporated  into  ISO/IEC  8825  by  making  the 
current  standard  Part  1  and  developing  a  revised  ISO/IEC  8825,  Specification  of  Encoding  Rules 
for  Abstract  Syntax  Notation  One  (ASN.l),  into  a  multi-part  standard  as  follows: 

•  DIS  8825-1  (Part  1):  Basic  Encoding  Rules  (BER),  1993 

•  DIS  8825-2.2  (Part  2):  Packed  Encoding  Rules  (PER),  1993  [SC21  N  7302] 

WDAM  1,  Lightweight  Encoding  Rules,  August  1993  [SC21  N  7920] 

•  DIS  8825-3  (Part  3):  Distinguished  and  Canonical  Encoding  Rules,  October  1992 
[SC21  N  7213]  (SC21  has  requested  its  Secretariat  to  conduct  an  national  body 
default  ballot  proposing  that  the  text  of  DIS  8835-3  be  merged  into  the  text  of 
DIS  8825-1  [Ref.  SC21  N  8081  1993]) 

•  DIS  8825-4  (Part  4):  Test  Suite  Structure  and  Test  Purposes,  July  1990 
[SC21  N  5019]. 

There  is  a  requirement  for  an  upper  layer  international  standard  or  recommendation  to 
specify  a  "quality  of  service,"  which  implies  that  the  use  of  transfer  syntaxes  will  provide,  within 
the  upper  layers,  a  high  level  of  security,  including  features  for  confidentiality  and  integrity.  This 
specification  defines  a  generic  transfer  syntax  whose  use  is  negotiated  by  the  presentation  protocol 
or  announced  in  an  ASN.  1  external.  It  provides  a  generic  transfer  syntax  that  can  be  applied  to  any 
abstract  syntax  defined  using  ASN.l.  [Ref.  SC21  N  6130  1991]  The  new  work  item  was 
accepted  provisionally  by  JTC1  with  a  request  that  SC21  reevaluate  the  need  for  the  project,  the 
wording  of  the  scope,  and  the  effort  required  for  progress  on  the  project.  Several  national  bodies 
have  raised  concerns  regarding  the  benefits  to  be  derived  from  progression  of  the  project 
[SC21  N  6604,  December  1991].  Generic  Transfer  Syntax  Providing  Upper  Layers  Security 45  is 
currently  in  WD  form. 

.  The  BER  use  a  "TLV”  approach  to  mapping  between  abstract  and  physical  data  wherein 
each  data  type  is  encoded  as  a  Tag,  a  Length,  and  a  Value.  The  tag  field  corresponds  to  the  label 
defined  by  the  data  type's  abstract  syntax,  the  length  field  normally  indicates  how  many  octets  are 
used  for  the  encoding  of  the  value  portion  of  the  data  type,  and,  finally,  the  value  of  the  data  type  is 
encoded. 

PER  achieve  a  more  compact  representation  than  that  achieved  by  the  BER.  For  each  value 
the  CER  select  just  one  encoding  from  those  allowed  by  the  BER,  eliminating  all  of  the  sender's 
options.  LWER  encode  and  decode  data  much  faster  than  the  BER. 

FIPS  121,  Videotext/Teletext  Presentation  Level  Protocol  Syntax,  adopts  ANSI  X3.110- 
1983  (with  the  same  title)  as  the  specific  data  syntax  to  be  used  at  the  presentation  layer  (and  some 


43  The  title  given  to  this  document  at  the  May /June  1991  meetings  in  Arks  was  Working  Draft  for  ASN.l 
Encoding  Rules  to  Provide  Upper  Layer  Security  and  Compression. 
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specific  semantics  for  the  application  layer)  for  videotext  and  teletext  applications.  It  is  based  on 
the  American  National  Standard  Code  for  Information  Interchange  (ASCII)  and  its  extensions. 
FIPS  121  provides  formats,  rules,  and  procedures  for  the  encoding  of  alphanumeric  text  and 
pictorial  information  to  be  used  with  broadcast  television  videotext  service. 

ITU-TS  Recommendations  F.200,  S.60,  S.61,  S.62,  and  S.70  define  the  service,  the 
terminal  equipment,  character  repertoire,  control  procedures,  and  supporting  transport  services  for 
Teletex.  ITU-TS  Recommendation  X.430  (Red  Book  1984)  describes  the  access  protocol  for 
Teletex  Terminals. 

A  new  standard,  ASC  X3.208-199x,  Transfer  Syntax  Description  Notation  (TSDN),  is 
being  developed  by  ANSI  X3.T2.  It  defines  a  notation  for  describing  the  structures  of  data 
volumes,  files,  records,  and  fields  to  facilitate  the  moving  of  data  files  between  computer  systems. 
While  it  provides  a  generalized  syntax  for  describing  the  data  records,  it  does  not  restrict  or  define 
their  contents.  It  was  originally  developed  as  an  internal  standard  by  the  Consultative  Committee 
on  Space  Data  Systems  (CCSDS)  to  handle  the  transmission  of  space  data.  [Ref.  Freeman  1991] 
It  is  currently  in  draft  form. 

9.11  Application  Layer 

The  Application  Layer  is  at  the  boundary  between  the  open  systems  environment  and  the 
application  processes  that  use  that  environment  to  exchange  data.  To  support  the  wide  variety  of 
possible  applications,  the  protocols  and  services  potentially  available  in  the  Application  Layer  are 
many  and  varied.  They  include  facilities  of  general  utility  to  a  wide  variety  of  applications  and 
facilities  specific  to  distinct  classes  of  applications. 

The  Application  Layer  directly  serves  applications  by  providing  the  required 
communication  support  A  communication  component  of  an  application — an  application  entity — 
communicates  with  a  peer  application  entity  using  an  application  protocol.  Some  application 
protocols  involve  only  two  objects  or  systems,  while  otters  involve  more.  Application  protocols 
are  described  using  information  models,  which  describe  how  a  class  of  information  structures  is 
organized. 

9.11.1  Common  Upper  Layer  Requirements  (CULR) 

The  Session,  Presentation,  and  Application  Layers  share  a  number  of  requirements. 
Standards  for  the  upper  layers  considered  together  are  the  following: 

•  ISO/IEC  10745,  Upper  Layer  Security  Model,  November  1993  [SC21  N  8334] 
(X.803) 

•  pDISP  11188-1,  Common  Upper  Layer  Requirements,  Part  1:  Basic  Connection- 
Oriented  Requirements,  July  1993 

•  pDISP  11188-2,  Common  Upper  Layer  Requirements,  Part  2:  ROSE-Based 
Requirements,  July  1993 

•  pDISP  1 1 188-3,  Common  Upper  Layer  Requirements,  Part  3:  Minimal  OSI  Upper 
Layer  Facilities,  July  1993 

•  DIS  1 1586-1,  Generic  Upper  Layer  Security  (GULS),  Part  1:  Overview,  Models  and 
Notation,  October  1993  [SC21  N  8182]  (X.830) 

•  DIS  1 1 586-2,  Generic  Upper  Layer  Security  ( GULS),  Part  2:  Security  Exchange 
Service  Element  (SESE)  Service  Definition,  October  1993  [SC21  N  8183]  (X.831) 
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•  DIS  11586-3,  Generic  Upper  Layer  Security  (GULS),  Part  3:  Security  Exchange 
Service  Element  ( SESE)  Protocol  Specification,  October  1993  [SC21  N  8184] 
(X.832) 

•  DIS  1 1586-4,  Generic  Upper  Layer  Security  (GULS),  Part  4:  Protecting  Transfer 
Syntax  Specification,  October  1993  {SC21  N  8185]  (X.833) 

•  WD  11586-5,  Generic  Upper  Layer  Security  (GULS),  Part  5:  Security  Exchange 
Service  Element  (SESE)  -  PICS  Proforma,  June  1993  [SC21  N  7912]  (X.834) 

•  WD  11586-6,  Generic  Upper  Layer  Security  (GULS),  Part  6:  Protecting  Transfer 
Syntax  -  PICS  Proforma,  June  1993  [SC21  N  7913]  (X.835). 

Upper  Layer  Security  Model.  The  purpose  of  the  Upper  Layer  Security  Model  is  to 
provide  standards  developers  with  the  architectural  model  for  the  development  of  application- 
independent  services  and  protocols  for  security  in  the  upper  layers  of  OSI  and  the  use  of  these 
services  and  protocols  to  fulfill  the  security  requirements  of  a  wide  variety  of  applications,  so  that 
the  need  for  application-specific  ASEs  to  contain  internal  security  services  is  minimized.  This 
standard  provides  detail  of  the  positioning  of  and  the  interaction  between  security  services  in  the 
upper  layers;  describes  the  handling  of  security  transformation  functions  (e.g.,  encipherment)  and 
security  check- value  functions  from  the  Application  and  Presentation  Layer;  introduces  the  concept 
of  a  security  exchange;  addresses  security  policy  and  security  state;  and  broadly  discusses  the 
provision  of  entity  authentication,  data  origin  authentication,  association  access  control,  resource 
access  control,  non-repudiation,  integrity,  and  confidentiality.  The  relationship  of  die  Upper  Layer 
Security  Model  to  other  security  standards  is  provided  in  the  Guide  to  Open  Systems  Security, 
December  1993  [SC21  N  8380]. 

Common  Upper  Layer  Requirements  (CULR).  pDISP  11188  is  a  multi-part  ISP 
that  specifies  general  requirements  on  the  use  of  OSI  connection-mode  protocols  by  application 
profiles.  The  CULR  does  not  contain  the  definition  of  any  complete  profiles  but  is  intended  to  be 
referenced  normatively  by  other  ISPs  that  define  application  profiles.  The  CULR  provides 
common  text  for  such  ISPs  or  other  referencing  specifications,  simplifying  the  specification 
process  on  facilitating  common  implementation  of  the  protocols  for  use  in  different  application 
profile  contexts. 

Generic  Upper  Layers  Security  (GULS).  The  GULS  standards  define  a  set  of 
generic  facilities  to  assist  in  the  provision  of  security  services  in  OSI  applications.  These  include 
the  following  [Ref.  SC21  N  8380  1993]: 

•  A  set  of  notional  tools  to  support  the  specification  of  (1)  selective  field  protection 
requirements  in  an  abstract  syntax  specification,  (2)  security  exchanges,  and 
(3)  security  transformations 

•  Service  definition,  protocol  specification,  and  PICS  proforma  for  an  application 
service  element.  Security  Exchange  Service  Element  (SESE),  to  support  die  provision 
of  security  services  in  the  Application  Layer 

•  A  specification  and  PICS  proforma  for  a  security  transfer  syntax  that  is  associated  with 
Presentation  Layer  support  for  security  services  in  the  Application  Layer. 

GULS  specializes  some  of  the  Application  Layer  concepts  of  the  Upper  Layer  Security 
Model.  It  should  be  viewed  as  only  a  starting  point  for  upper  layers  security,  as  it  lacks  any 
specifics  on  how  particular  classes  of  mechanisms  may  be  used  to  support  generic  security 
requirements.  Its  tools  address  security  transformations  (e.g.,  encryption,  digital  signatures)  as 
required  for  confidentiality,  integrity,  data  origin  authentication,  and  possibly  non-repudiation. 
[Ref.  DRA  1994] 

Chapter  9 


179 

UNCLASSIFIED 


Network  Service  Standards 


UNCLASSIFIED 


9.11.2  Application  Layer  Structure  (ALS) 

ISO  9545,  Application  Layer  Structure  (ALS),  was  originally  published  by  ISO  in 
December  1989.  In  1993,  a  new  version,  with  extended  ALS  (XALS,  ISO  9545:1993)  was 
published.  ISO  9545  defines  the  nature  of  standards  in  the  Application  Layer  and  the  relationships 
among  them,  the  architectural  framework  in  which  individual  OSI  Application  Layer  protocols 
shall  be  developed,  and  the  categories  of  identifiable  objects  that  are  necessary  for  the  specification 
and  operation  of  protocols.  It  also  relates  distributed  information  processing  activities  to  the 
standards  in  the  Application  Layer.  Key  concepts  from  the  ALS  are  the  following: 

•  Association  (application  association) — a  cooperative  relationship  between  two  AE 
invocations  for  the  purpose  of  communicating  information  and  coordinating  their  joint 
operation.  This  relationship  is  formed  by  the  exchange  of  application  protocol  control 
infoimation  using  the  Presentation  Service. 

•  Application  context — a  set  of  rules  shared  in  common  by  two  service  element  (SE) 
invocations  in  order  to  enable  their  cooperative  operation.  The  application  context  is 
an  example  of  a  shared  conceptual  schema.  SC21  N  5502  is  a  liaison  to  ITU-TS 
Q23/VII  concerning  application  context  negotiation  during  association  establishment 
Other  relevant  references  include: 

Guidelines  for  Application  Context  Definition  [SC2 1  N  607 1 ] 

Discussion  Paper  on  Application  Context  Negotiation  [SC21  N  6122J 
A  Possible  Approach  for  Application  Context  Negotiation  During  Association 
Establishment  [SC21  N  6123]. 

•  Single  association  object  (SAO) — the  collection  of  things  in  an  AE  invocation  related 
to  a  single  application  association. 

•  Single  association  control  function  (SACF) — the  component  of  a  single  association 
object  that  represents  the  use  of  those  rules  in  the  application  context  concerning 
interactions  among  ASEs  within  a  single  application  association. 

•  Multiple  association  control  function  (MACF) — a  component  of  the  AE  invocation  that 
coordinates  the  interactions  among  multiple  associations  within  an  AE  invocation  in 
order  to  provioc  a  coordinated  service. 

The  purpose  of  XALS  is  to  supplement  ISO  9545  by  providing  a  more  complete 
framework  for  development  of  Application  Layer  protocol  standards  that  use  other  Application 
Layer  protocol  standards.  A  central  focus  of  XALS  is  extension  of  the  architecture  for  use  of 
multiple  associations.  [Ref.  SC21  N  4901  1990]  The  text,  which  was  approved  in  March  1993, 
is  in  SC21  N  7815.  It  is  formatted  as  a  revision  to  the  ALS  standard  (ISO  9545:1993)  intended  for 
publication  as  a  new  edition,  not  as  an  amendment  The  new  edition  offers  greater  power  and 
flexibility  than  the  first  edition.  It  includes  a  multi-level  structure  and  more  on  control  function  and 
ASO-type  specification.  [Ref.  SC21  N  7817  1993] 

XALS  provides  a  revised  ALS  model  that  is  significantly  richer  in  scope  and  descriptive 
capability  than  is  provided  in  ISO  9545.  As  a  result  it  provides  more  options  for  the  specification 
of  Application  Layer  standards.  Examples  of  new  features  are: 

•  Defining  Application  Service  Elements  (ASEs),  application  service  objects  (ASOs), 
and  control  functions.  An  ASO  is  made  up  of  one  or  more  ASEs  and/or  ASOs,  and  a 
control  function.  A  control  function  is  the  component  of  an  ASO  that  controls  the 
interactions  among  ASEs  and/or  ASOs  within  the  containing  ASO. 

•  Providing  guidance  for  ASE  specifications  in  the  areas  of  the  reference  model  the  ASE 
supports,  the  service  definition,  the  abstract  protocol  definition,  and  the  ASE 
environment  requirements  specification. 
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•  Addressing  peer-to-peer  (application  level)  relationships  as  well  as  the  established 
concept  of  application  association,  such  as  are  used  on  MHS,  TP,  EDI,  and  Directory. 

•  Accommodating  both  peer-to-peer  and  client-server  interaction  styles.  (ROSE 
supports  both  styles  of  interaction.  X- Windows  and  DO  AM  use  client-server  styles, 
for  which  the  terminal  in  the  X-Window  environment  is  the  server,  whereas  the 
terminal  in  the  DOAM  model  is  the  client) 

As  a  result  of  using  the  XALS  model,  the  UK  believes  that  there  is  a  need  to  provide  some 
guidance  to  those  groups  that  are  making  use  of  it  in  their  modelling  and  specification  of 
Application  Layer  functions.  In  particular,  there  is  a  need  for  guidance  on  how  to  develop  ASE 
and  ASO  specifications  that  may  be  used  in  a  variety  of  AE  configurations.  This  is  because  there 
are  conflicts  in  the  ASE  specification  regarding  their  assumptions  about  the  use  of  supporting 
services  such  as  ACSE  and  Session  Resynchronization.  Moreover,  there  are  cases  of  both 
overlapping  and  conflicting  functionality.  The  United  Kingdom  therefore  proposes  to  amend  the 
ASE  specifications  to  achieve  compatibility  and  produce  a  specification  for  the  combination  of  the 
ASEs.  [Ref.  SC21  WG6  N  1155  1992] 

An  amendment  to  ISO  9545  for  connectionless  mode  transmission  has  been  in  the  working 
draft  stage  since  1988  and  has  lacked  an  editor  and  target  dates.  In  June  1993,  the  project  was 
cancelled. 

Methodology  and  Guidelines  for  the  Development  of  Application  Layer  Protocols, 
January  1990,  is  being  developed  to  provide  a  discipline  for  development  of  application  protocol 
standards  in  order  to  generate  precise  specifications.  It  is  now  a  working  draft  [SC21  N  8410]. 

A  question  concerning  Versions  and  Extensibility  [SC21  N  6060,  May  1991]  of  the  ALS 
has  come  to  the  attention  of  SG6.  Variants  of  Application  Layer  protocols  may  arise  for  a  number 
of  reasons;  for  example,  a  protocol  may  be  revised  to  support  additional  capabilities  or  to  provide 
different  capabilities.  It  is  important  to  ensure  that  Application  Layer  protocols  are  designed  so  as 
to  enable  implementations  of  different  variants  to  co-exist  and  interwork  (where  feasible)  and, 
equally  importantly,  to  provide  an  environment  that  facilitates  the  orderly  migration  from  one 
network  systems  configuration  to  another.  SC21  N  6965,  June  1992,  the  revised  draft  answer  to 
this  question,  was  approved  in  October  1992. 

SC21  N  6967  Modelling  Recovery  in  the  Application  Layer,  June  1992,  ISO  9545 
WDAM  2  adds  to  concepts  and  principles  of  ISO  9545  by  categorizing  the  nature  of  failures  visible 
in  the  Application  Layer  and  defining  the  concepts  and  modelling  principles  for  recovery.  Target 
dates  are  CD  in  July  1993,  DIS  in  July  1994,  and  IS  in  July  1995.  It  is  to  be  merged  with  ISO 
9545:1993. 

9.11.3  Application  Service  Elements  (ASEs) 

The  services  performed  in  the  Application  Layer  of  the  OSI  model  can  be  thought  of  as 
application  processes  whose  communication  aspects  are  represented  by  application  entities.  The 
OSI  Application  Layer  structure  permits  an  application  process  to  have  multiple  communication 
aspects  and,  hence,  multiple  application  entities. 

An  application  entity  is  a  collection  of  one  or  more  ASEs.  Each  of  the  peer  application 
entities  have  identical  ASEs.  Additionally,  each  ASE  talks  only  with  its  peer  in  the  remote 
application  entity.  The  remainder  of  this  section  discusses  the  following  ASEs  (the  SESE  was 
described  in  Section  9.1 1.1  above): 
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•  Association  Control  Service  Element  (ACSE),  which  provides  association  control  and 
manages  connections  between  application  entities 

•  Commitment,  Concurrency,  and  Recovery  (CCR),  which  provides  fault  tolerance  and 
manages  error  indication  and  recovery 

•  Reliable  Transfer  Service  Element  (RTSE),  which  manages  bulk  data  transfers 

•  Remote  Operations  Service  Element  (ROSE),  which  manages  request/reply 
interactions 

•  Remote  Call  Procedure  (RPC) 

•  User  ASE  defined  in  Transaction  Processing. 

A  typical  application  process  might  have  a  user  element  orchestrating  the  application 
entities'  actions.  This  user  element  could  use  RTSE  services  to  manage  associations  via  ACSE 
services  and  could  use  the  ROSE,  which  invokes  RTSE  services,  to  transfer  data  through  the  use 
of  the  presentation  service. 

9.11.3.1  Association  Control  Service  Element  (ACSE) 

The  ACSE  is  defined  for  the  purpose  of  managing  application  associations.  It  provides 
facilities  for  the  establishment  and  release  of  application  associations.  An  application  association  is 
a  presentation  connection  with  additional  application  layer  semantics  such  as  application  context 
negotiation  and  peer-to-peer  authentication.  At  present,  there  is  a  one-to-one  mapping  between 
application  associations  and  presentation  connections.  However,  future  versions  of  the  ACSE 
standard  might  permit  a  presentation  connection  to  be  reused  for  a  new  association  or  multiple 
associations  to  be  interleaved  onto  a  single  presentation  connection.  Because  the  sole  purpose  of 
ACSE  is  to  manage  application  associations,  ACSE  does  not  provide  any  data  transfer  service 
elements.  Thus,  in  any  application  context  containing  ACSE,  there  are  one  or  more  user-ASEs  that 
will  provide  some  data  transfer  service  elements.  [Ref.  Tang  1992] 

The  ACSE  provides  service  to  both  user  elements  and  to  specific  application  service 
elements.  The  purpose  of  this  service  is  to  support  the  establishment,  maintenance,  and 
termination  of  application  associations.  Because  the  ACSE  manages  the  association  of  application 
entities,  all  OSI  applications  contain  an  ACSE.  The  services  provided  by  ACSE  are: 

•  ASSOCIATE,  which  sets  up  an  application  association 

•  RELEASE,  which  releases  an  association  in  an  orderly  fashion 

•  ABORT,  which  terminates  application  association  simultaneously  with  the  underlying 
presentation  and  session  connections. 

The  ISO  definition  of  the  service  is  technically  aligned  with  the  1988  ITU-TS 
recommendation  on  the  ACSE  service.  The  differences  between  the  ISO  definition  and  the  ITU- 
TS  definition  are  quite  small  and  are  not  expected  to  affect  interoperability  between 
implementations  written  against  either  document.  [Ref.  Rose  1990]  SG7  of  ITU-TS  is 
progressing  the  second  editions  of  the  ACSE  Protocol  and  Service  while  SC21  has  not  The  texts 
approved  by  ITU-TS  differ  from  the  texts  of  record  in  SC21,  however,  the  differences  are  believed 
to  be  editorial.  [Ref.  SC21  N  7868  1993]  SC21  has  recently  begun  work  on  second  editions  to 
ISO  8649  and  8650. 
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The  relevant  ISO  standards  are  the  following: 

•  ISO  8649,  Service  Definition  for  the  Association  Control  Service  Element  (ACSE), 
April  1992  (X.217) 

DAM  3:  Application  Context  Negotiation  During  Association  Establishment 
[SC2 1  N  8046,  September  1993] 

•  DIS  8649.2,  Service  Definition  for  the  Association  Control  Service  Element  (ACSE), 
Edition  2  (IS  expected  November  1994) 

•  ISO  8650,  Protocol  Specification  for  the  Association  Control  Service  Element 
(ACSE),  April  1992  (X.227) 

DAM  2:  Application  Context  Negotiation  During  Association  Establishment 
[SC21  N  8047,  September  1993] 

WDAM  3:  A-Context  Management  Service  (DAM  expected  June  1994;  AM 
expected  June  1995) 

•  DIS  8650-1,  Protocol  Specification  for  the  Association  Control  Service  Element 
(ACSE),  Edition  2  (IS  expected  November  1994) 

•  ISO  8650-2,  ACSE,  Part  2:  PICS  Proforma  (X.247) 

•  ISO/IEC  10035,  Connectionless  ACSE  Protocol  Specification  (X.237) 

•  DIS  10035-2,  Connectionless  ACSE  Part  2:  PICS  Proforma,  September  1993  [SC21 
N  7870  rev.]  (X.257)  (initiation  of  ITU-TS  approval  expected  November  1994) 

•  ISO/IEC  10169-1,  Conformance  Test  Suite  for  the  ACSE  Protocol,  Part  1:  Test  Suite 
Structure  and  Test  Purposes,  September  1991  [SC21  N  6421]. 

•  WD  10169-2,  Conformance  Test  Suite  for  the  ACSE  Protocol,  Part  2:  Common 
ACSE  Abstract  Test  Suite  (project  risks  cancellation  by  SC21  in  the  absence  of  written 
confirmation  that  the  regional  workshops  will  provide  a  WD  by  June  1994).  [Ref. 
SC21  N  7728  1993]) 

A  discussion  paper  [SC21 N  5835]  on  association  pools  as  an  extension  of  ACSE  appeared 
in  April  1991.  The  United  States  then  requested  that  WG6,  in  collaboration  with  TP  and  RPC, 
consider  extending  ACSE  to  provide  support  for  facilities  of  XALS  and  Application  Pools.  The 
project  would  generate  amendments  to  ACSE  service  definition  and  protocol  (ISO  8649  and  8650) 
specification  to  support  XALS  and  Association  Pools.  WD  status  was  proposed  few  June  1993, 
CD  for  June  1994,  and  DIS  for  January  1995.  [Ref.  SC21  N  6798  1992] 

In  June  1992,  SC21  accepted  an  NP  for  Extension  to  ACSE  Covering  ASOs  and  ASO- 
associations.  The  amendments  to  ISO  8649  and  8650  will  add  extensions  in  two  areas: 

•  ASO  addressing  extension  to  die  existing  A- ASSOCIATE  service 

•  Providing  a  standardized  way  to  establish  and  release  ASO-associadons. 

WDAM  was  planned  in  November  1992,  PDAM  in  July  1993,  DAM  in  July  1994,  and  AM  in  July 
1995.  [Ref.  SC21  N  7014  1992]  Although  this  NP  has  met  the  criteria  for  acceptance  into  the 
JTC1  program  of  work,  several  national  bodies  question  die  user  requirements  for  this  new  work 
item  (NWI).  SC21/WG8  (formerly  WG6)  is  requested  to  respond  to  the  comments  received.  [Ref. 
SC21  N  7723  1993] 

9.11.3.2  Commitment,  Concurrency,  and  Recovery  (CCR)4* 

The  CCR  service  and  protocol  standards  are  used  to  supply  a  more  fault  tolerant  association 
than  is  possible  with  ACSE  The  ACSE  has  two  baric  flaws  [Ref.  Stallings  1987]: 


46  Portions  of  this  lection  are  excerpted  from  [Tag  1991]. 
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•  A  system  crash  leaves  ambiguous  results. 

•  A  lack  of  coordination  of  multiple  systems  could  produce  inconsistent  results. 

These  flaws  are  resolved  in  CCR  by  adding  the  concept  of  commitment.  The  master  asks  the 
subordinate  for  a  commitment  to  perform  a  task  (request)  before  the  call  for  the  execution  of  the 
task  (commitment)  is  made.  This  allows  for  a  record  to  be  kept  by  both  the  master  and  the 
subordinate  as  to  the  status  of  the  task.  Use  of  CCR  can  have  an  adverse  performance  impact. 

Concurrency  is  a  concept  that  is  necessitated  by  the  concept  of  commitment.  Once  an 
application  entity  has  offered  to  commit,  conflicting  requests  cannot  be  made  against  the  application 
until  the  commitment  is  fulfilled.  Concurrency  is  the  mechanism  by  which  committed  resources 
are  "frozen"  until  the  committed  application  is  completed. 

Recovery  is  the  process  of  determining  the  status  of  a  task  after  an  application  or 
communication  failure.  The  CCR  service  provides  partial  support  for  recovery;  however,  the 
actual  recovery  process  is  specific  to  the  application. 

The  CCR  standard  (ISO  980S)  provides  the  communication  mechanism  for  the  two-phase 
commit  protocol  on  a  single  application  association  between  two  CCR  service  users.  It  provides 
the  CCR  service  users  with  service  primitives  to  commit,  rollback,  and  recover  from  failures.  It 
does  not  provide  any  data  transfer  facilities.  Therefore,  the  CCR-ASE  must  be  used  with  one  or 
more  user-ASEs  that  can  supply  the  data  needed  for  an  atomic  action. 

The  CCR  ASE  provides  a  set  of  service  elements  to  coordinate  two  AEs  involved  in  an 
atomic  action.  An  atomic  action  is  a  well-defined  set  of  operations  that  has  four  properties: 
atomicity,  consistency,  isolation,  and  durability  (ACID).  The  atomicity  property  means  that,  to  an 
outside  observer,  either  all  of  the  operations  are  completed  or  none  of  them  is  executed.  The 
consistency  property  means  that  the  operations  are  performed  correctly  with  respect  to  the 
application  semantics.  The  isolation  property  means  that  any  partial  results  of  the  operations 
composing  the  atomic  action  are  not  accessible  before  the  completion  of  the  atomic  action.  Finally, 
the  durability  property  means  that  the  action  must  endure  a  communication  or  an  application  failure. 

To  preserve  the  ACID  properties,  the  two-phase  protocol  taken  from  database  theory  is 
used.  This  protocol  ensures  that  the  state  is  remembered  prior  to  any  work,  so  that  an  earlier 
consistent  state  can  be  recreated  if  the  work  is  damaged.  (The  notion  of  recreating  an  earlier  state  is 
called  rollback.)  CCR  supports  the  communication  aspects  of  the  two-phase  protocol.  For 
example,  a  CCR  service  user  can  use  CCR  service  elements  to  request  its  peer  to  offer 
commitment,  to  signal  to  its  peer  that  it  is  ready  to  commit,  and  to  command  a  peer  to  rollback  or  to 
initiate  recovery. 

Bound  data  refers  to  the  data  whose  state  may  be  affected  by  an  atomic  action.  The  two- 
phase  protocol  makes  sure  that  the  modification  of  the  bound  data  is  done  indivisibly. 
Commitment  releases  bound  data  in  the  final  state  while  rollback  releases  bound  data  in  the  initial 
state. 

Atomic  action  data  consists  of  state  information  about  an  atomic  action.  When  a 
communication  or  an  application  failure  occurs,  a  CCR  service  user  relies  upon  the  atomic  action 
data  to  perform  recovery.  CCR  uses  the  presumed  rollback  recovery  mechanism.  For  this 
mechanism,  the  subordinate  acquires  the  recovery  responsibility  when  it  decides  to  offer 
commitment,  while  the  superior  acquires  the  recovery  responsibility  when  it  decides  to  order 
commitment 
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There  are  three  standards  (dating  to  CCR: 

•  ISO/IEC  9804,  Service  Definition  for  the  Commitment,  Concurrency,  and  Recovery 
Service  Element  (X.851) 

•  DIS  9804.2,  Service  Definition  for  the  Commitment,  Concurrency,  and  Recovery 
Service  Element,  Edition  2  (ballot  closed  November  1993) 

•  ISO/IEC  9803,  Protocol  Specification  for  the  Commitment,  Concurrency,  and 
Recovery  Service  Element  (X.852) 

•  ISO/IEC  9803-1,  Protocol  Specification  for  die  Commitment,  Concurrency,  and 
Recovery  Service  Element,  Edition  2  of  ISO/IEC  9803 

•  DIS  9805-2.2,  Protocol  Specification  for  CCR,  Part  2:  PICS  Proforma.  (X.853)  (IS 
status  expected  September  1994). 

ISO/IEC  9804  and  ISO/IEC  9803  have  three  amendments:  Enhancements,  Session  Mapping 
Changes  (Additional  Synchronization  Functionality),  and  Restart.  Amendment  1  for  each  has 
reached  PD  AM  status,  and  Amendment  2  has  reached  AM  status. 

In  January  1990,  a  CCR  Conformance  Test  Suite  was  proposed  as  a  new  work  item  [SC21 
N  4279].  CD  status  was  expected  in  June  1992.  This  project  risks  cancellation  by  SC21  in  die 
absence  of  written  confirmation  that  the  regional  workshops  will  provide  a  WD  by  June  1994. 

Another  new  work  item  [SC21  N  612 6]  has  been  accepted  for  writing  a  formal  description 
of  the  CCR  service  and  protocol  using  LOTOS.  WG6  has  developed  PDTRs  for  a  LOTOS 
Description  of  the  CCR  Service,  PDTR  11589,  June  1993  [SC21  N  7876]  and  Protocol,  PDTR 
1 1590,  June  1993  [SC21  N  7877]. 

9.11.3.3  Reliable  Transfer  Service  Element  (RTSE) 

RTSE  provides  a  service  of  reliably  moving  arbitrarily  large  objects  from  one  application 
entity  Jo  another.  The  RTSE  accomplishes  this  service  by  dealing  with  ASN.l  data  types  rather 
than  a  string  of  octets  and  by  abstracting  the  complexity  of  the  underlying  service  session  into  an 
easily  usable  service. 

If  a  network  failure  occurs  while  a  bulky  application  protocol  data  unit  (APDU)  such  as  a 
large  file  or  a  long  message  is  transferred  over  a  wide  area  network,  then  the  entire  APDU  may 
have  to  be  retransmitted.  RTSE  ensures  that  the  APDU,  whatever  its  size,  is  transferred  exactly 
once  or  that  the  sender  is  warned  of  an  exception.  RTSE  provides  such  service  through  the  use  of 
the  session  service.  To  the  RTSE  users,  RTSE  provides  a  simple  reliable  transfer  facility  by 
hiding  the  complexity  of  the  session  service.  The  RTSE  standard,  as  specified  in  ISO/IEC  9066, 
is  primarily  used  by  MHS.  Formerly  called  RTS  (Reliable  Transfer  Server),  RTSE  is  used  to 
regulate  and  control  mail  transfer  between  local  and  remote  MTAs.  In  particular,  it  is  used  by  the 
PI  protocol  over  a  wide  area  network.  When  sending  mail  over  a  reliable  LAN,  the  overhead 
incurred  by  RTSE  cannot  not  be  justified,  hence  RTSE  is  not  used.  [Ref.  Tang  1992] 

When  an  application  context  contains  an  RTSE,  it  is  the  sole  user  of  ACSE  services  and  die 
presentation  service.  The  RTSE  is  used  to  signal  to  application  elements  that  a  transfer  has  been 
completed  successfully.  The  ISO  standard  for  RTSE  comes  in  two  parts  with  a  third  under 
development: 

•  ISO/IEC  9066-1,  Reliable  Transfer,  Part  1:  Model  and  Service  Definition  (X.218) 

•  ISO/IEC  9066-2,  Reliable  Transfer,  Part  2:  Protocol  Specification  (X.228) 

•  DIS  9066-3,  Reliable  Transfer,  Part  3:  PICS  Proforma  (X.248)  [SC21  N  7677, 
March  1993]  (initiation  of  ITU-TS  ballot  expected  June  1993). 
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Since  RTSE  was  developed  in  the  early  MHS  work  that  preceded  the  definition  of  the 
presentation  service  and  ULA,  it  demands  syntax  conversions  be  done  in  the  Application  Layer 
(rather  than  in  the  Presentation  Layer  as  specified  by  the  ULA).  Thus,  RTSE  does  not  fit  well  with 
the  OSI  ULA.  [Ref.  SC21  N  5997  1991] 

9.11.3.4  Remote  Operations  Service  Element  (ROSE) 

Remote  operations  are  a  popular  technique  for  building  distributed  applications.  The  ROSE 
manages  operations  for  application  entities  via  a  mechanism  that  is  analogous  to  services  performed 
by  CCR  for  data  transfer.  ROSE  provides  the  facilities  to  invoke  a  remote  operation  on  another 
computer,  to  have  the  result  of  the  operation  or  an  error  message  returned  to  the  invoker,  or  to  have 
the  remote  operation  rejected  as  invalid  [IGOSS  1993]. 

ROSE  provides  the  communication  support  for  a  typical  request-reply  interaction.  In  an 
application  context  containing  ROSE,  there  are  one  or  more  user-ASEs  that  supply  the  requests  or 
replies  in  the  form  of  remote  operations  to  ROSE.  On  receiving  a  remote  operation,  the  ROSE 
protocol  constructs  a  ROSE  APDU  and  sends  it  using  either  RTSE  or  the  presentation  service. 
The  ROSE  service  definition  provides  service  elements  to  invoke  an  operation,  to  return  a 
result/reply,  or  to  reject  the  execution  of  an  operation.  It  also  supports  the  use  of  linked 
operations.  For  example,  using  the  linked  operations  feature,  a  management  agent  can  link 
multiple  replies  to  a  single  request  from  a  manager.  Before  a  ROSE  user  can  invoke  any  operation, 
it  must  first  register  a  set  of  remote  operations  with  the  ROSE  service  provider  even  before  an 
application  association  is  made  with  a  peer.  At  the  time  of  application  association  establishment,  it 
must  specify  whether  the  application  context  should  contain  RTSE  or  not  [Ref.  Tang  1992] 

In  its  most  primitive  form,  an  operation  is  a  simple  request/reply  interaction.  The  request, 
or  invocation,  consists  of: 

•  An  operation  number — a  unique  identifier  for  the  operation  to  be  performed 

•  An  arbitrarily  complex  argument — the  "input"  for  the  operation 

•  An  invocation  identifier — a  unique  identifier  for  a  particular  invocation 

•  A  linked  invocation  identifier — an  indication  that  this  operation  is  being  invoked  as  a 
part  of  the  processing  of  another  invocation. 

An  invocation  can  have  one  of  three  outcomes: 

•  A  result — an  invocation  identifier  corresponding  to  the  operation  that  succeeded  and  an 
arbitrarily  complex  result 

•  An  error — an  invocation  identifier  corresponding  to  the  operation  that  failed,  an  error 
number  uniquely  identifying  the  error  that  occurred,  and  an  arbitrarily  complex 
parameter  that  provides  clarifying  information 

•  A  rejection — an  invocation  identifier  corresponding  to  the  operation  that  was 
performed  and  a  reason  that  describes  the  rejection  that  occurred. 

The  standards  that  apply  to  the  ROSE  are: 

•  ISO  9072-1:1989,  Remote  Operations,  Part  1:  Model,  Notation  and  Service 
Definition,  Revised  Edition,  September  1989  [SC21  N  3881]  (X.219) 

PDAM  1,  Enhancements  to  Service  Definition,  April  1992  [SC21  N  6717]  (to 

JTC1  for  endorsement  to  cancel  the  project) 

•  ISQflEC  9072-1:1993,  Remote  Operations,  Part  1:  Concepts,  Model  and  Notation, 
Edition  2,  March  1993  [SC21  N  7669]  (passed  DIS  ballot  in  October  1993)  (X.219) 
(sec  DIS  13712-1) 

PDAM  1,  Built-In  Operations,  June  1993  [SC21  N  8073] 
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•  ISO/IEC  9072*2:1989,  Remote  Operations,  Put  2:  Protocol  Specification,  Revised 
Edition,  September  1989  [SC21  N  3882]  (X.229) 

•  PD  AM  1,  Enhancements  to  Protocol  Specification,  April  1992  [SC21  N  6718] 

(toJTCl  for  endorsement  to  cancel  the  project) 

•  ISO/IEC  9072-2:1993,  Remote  Operations,  Part  2:  Service  Definition,  Edition  2, 
March  1993  (passed  DIS  ballot  in  October  1993)  [SC21  N  7670]  (see  DIS  13712-2) 

PD  AM  1,  Mapping  to  A-UNITDATA  and  Built-In  Operations,  July  1993 
[SC21  N  8074] 

•  ISO/IEC  9072-3:1993,  Remote  Operations,  Part  3:  Protocol  Specification, 
March  1993  (passed  DIS  ballot  in  October  1993)  [SC21 N  8074]  (see  DIS  13712-3) 

PD  AM  1,  Mapping  to  A-UNITDATA  and  Built-In  Operations,  June  1993 
[SC21  N  8075] 

•  DIS  9072-4,  Remote  Operations,  Part  4:  PICS  Proforma,  December  1993 
[SC21  N  7678]  (initiation  of  ITU-TS  approval  ballot  expected  November  1994) 
(X.249)  (see  DIS  13712-4) 

•  DIS  13712-1,  Remote  Operations,  Part  1:  Model,  1993  (X.880)  (initiation  of  ITU-TS 
ballot  approval  February  1994)  (see  9072-1) 

-  PDAM1,  Built-In  Operations,  January  1994  [SC21 N  8406] 

•  DIS  13712-2,  Remote  Operations,  Part  2:  Service,  1993  (X.881)  (initiation  of 
ITU-TS  ballot  approval  February  1994)  (see  9072-2) 

PDAM1,  Mapping  to  A-UNITDATA  and  Built-In  Operations,  January  1994 
[SC21N8407] 

•  DIS  13712-3,  Remote  Operations,  Part  3:  Protocol,  1993  (X.882)  (initiation  of 
ITU-TS  ballot  approval  February  1994)  (see  9072-3) 

PDAM1,  Mapping  to  A-UNITDATA  and  Built-In  Operations.  January  1994 
[SC2IN8408] 

•  DIS  13712-4,  Remote  Operations,  Part  4:  PICS  Proforma,  1993  (X.883)  (initiation 
of  ITU-TS  ballot  approval  November  1994)  (see  9072-4) 

•  WD  13712-5,  Remote  Operations,  Part  5:  Enhancements,  1993  (initiation  of  ITU-TS 
ballot  approval  June  1995). 

ROSE  is  a  set  of  communications  facilities  to  distributed  applications.  ROSE  was  derived 
from  the  Remote  Operations  (RO)  service  defined  in  ITU-TS  MHS-84.  The  standard  (ISO  9072) 
also  provides  a  notation  for  defining  them  (an  extension  of  ASN.l).  Remote  operations  service  is 
asynchronous,  so  a  client  need  not  wait  for  a  response  before  invoking  another  operation.  ISO 
9072  defines  the  structure  of  remote  operations  and  the  abstract  services  and  protocol  to  support 
them.  The  services  are  generic  in  that  their  effect  on  the  remote  object  is  defined  by  their  users. 

The  basic  interaction  with  a  remote  object  is  an  operation  that  is  similar  to  a  procedure  call 
in  a  programming  language.  An  operation  is  invoked  on  a  target  object,  to  which  the  operation 
argument  is  passed.  Operations  have  one  of  two  possible  structures,  and  invocations  have  two 
possible  outcomes.  Some  operations  return  either  a  Result,  when  they  are  executed  successfully, 
or  an  Error,  other  operations  produce  only  a  response  (Error)  if  the  operation  fails. 

The  emerging  four-part  revision  of  ROSE  covers  only  a  subset  of  extensions  that  are 
needed.  For  successful  collaboration  between  JTC1  and  ITU-TS  on  ROSE,  it  w ps  necessary  for 
SC21  to  propose  yet  another  NWI  [SC21  N  7013]  in  May  1992  [Ref.  SC21  N  6719  1992],  which 
received  adequate  National  Body  support  to  be  forwarded  to  JTC1  for  NP  letter  ballot  The  NP 
would  enhance  the  three-part  ROSE  specifications  [SC21  N  6716-6718]  through  amendments  to 
include  the: 
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•  Addition  of  built-in  operations  for  optional  inclusion  in  any  application  context 

•  Mapping  of  ROSE  APDUs  onto  the  A-UNITDATA  service 

•  Addition  of  various  QoS  fields  in  ROSE  information  objects  and  new  information 
object  classes  for  specifying  QoS. 

PDAM  status  was  achieved  in  March  1993.  DAM  is  expected  in  February  1994  and  AM  in 
February  1995.  [Ref.  SC21  N  7013  1992] 

9.11.3.5  Remote  Procedure  Call  (RPC) 

RPC  extends  the  local  procedure  call  to  a  distributed  environment  In  a  RPC,  a  process  can 
invoke  a  remote  procedure  as  if  it  were  invoking  a  local  procedure.  By  hiding  the  communication 
details  from  the  invoking  process,  RPC  promotes  applications  portability.  RPC  is  extremely 
useful  for  distributed  applications.  For  example,  a  client  application  involving  a  computationally 
complex  procedure  can  use  RPC  to  have  that  procedure  run  on  a  remote  high  speed  computer. 
This  will  improve  the  throughput  of  the  application  dramatically.  Since  RPC  only  defines  a  style 
of  interaction,  it  can  be  combined  with  any  OSI  application  standard  that  leaves  the  data  transfer 
facilities  open  to  the  users.  For  example,  it  can  be  used  with  the  OSI  Transaction  Processing 
standard.  Since  TP  does  not  provide  a  method  for  transferring  data,  it  is  up  to  a  TP  application  to 
determine  its  own  envelope.  [Ref.  Tang  1992] 

The  RPC  standard  specified  a  RPC  computational  model  and  a  RPC  engineering  model. 
The  RPC  computational  model  describes  the  style  of  program  interaction,  while  the  RPC 
engineering  model  describes  the  protocol  used  to  support  the  RPC  computational  model.  Before  a 
client  can  request  a  service  from  a  server,  it  must  first  obtain  a  service  reference  that  includes  the 
location  of  a  server  in  particular.  With  the  service  reference,  the  client  can  establish  a  binding  with 
the  server  and  start  invoking  services.  The  trading  service  provides  the  means  for  clients  to  obtain 
service  references.  In  general,  trading  refers  to  the  process  of  importing,  exporting,  and  matching 
proposals.  [Ref.  Tang  1992] 

The  ECMA  standard  for  RPC  is  ECMA  127.  As  defined  in  ECMA  127,  an  RPC  is  a 
communication  service  to  transfer  procedure  calls  to  a  remote  server  and  return  results,  errors,  or 
associated  call  backs.  One  of  the  central  notions  of  RPC  is  dial  of  a  stub.  A  stub  builds  protocol 
information  for  RPCs  (marshalling)  and  translates  protocol  information  to  server  procedure  calls 
(unmarshalling).  ECMA  127  defines  an  Interface  Definition  Notation  (IDN)  to  facilitate  the 
transfer  of  data  across  an  interface.  The  IDN  supports  a  union  of  programming  language-specific 
data  types  such  as  pointers,  arrays,  and  records,  and  primitive  data  types  such  as  integers  and  bit 
strings.  ECMA  127  limits  the  number  of  outstanding  procedure  calls  to  one  per  association,  in 
order  to  prevent  livelock  situations  and  preserve  fairness;  it  is  unclear  if  this  is  the  most  efficient 
solution  to  the  livelock  problem.  SC21/WG6  proposes  to  address  RPC  using  an  IDN  that  is  based 
on  abstract  data  types  rather  than  on  a  union  of  programming  language-specific  data  types. 

Text  for  DIS  10148,  Basic  Remote  Procedure  Call  (RPC)  Using  OSI  Remote  Operations 
[SC21  N  3463],  was  based  on  ECMA  127  and  submitted  in  1989  on  a  fast-track  ballot,  which 
failed.  DIS  10148  was  withdrawn,  and  a  September  1989  proposal  for  a  new  work  item  was 
accepted  by  JTC1  in  May  1990.  The  draft  standard,  DIS  1 1578,  has  five  parts: 

•  DIS  11578-1,  Part  1  .Model  [SC21  N  8212,  September  1993] 

•  DIS  11578-2,  Part  2,  Interface  Definition  Notation;  uses  data  types  defined  by 
SC22/WGI I  and  defines  a  mapping  of  these  to  ASN.l  [SC2I  N  8213,  September 
1993] 
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•  DIS  11578*3,  Put  3,  Service  Definition :  Basic  RPC  ASO  Service  [SC21  N  8214, 
September  1993] 

•  DIS  11578*4,  Put  4,  Protocol  Specification :  Basic  RPC  ASO  [SC21  N  8215. 
September  1993] 

•  WD  11578-5,  Part  5.  PICS  Proforma  [SC21  N  6111,  June  1991].  (SC21  is 
considering  canceling  WD  1 1578-5  in  the  absence  of  an  Editor  and  WD.  [Ref.  SC21 
N  7728  1993]) 

Some  of  the  work  being  undertaken  in  ECMA  with  respect  to  RPC  includes  die  following: 

•  Position  on  RPC  Modelling  [SC21 N  5816,  March  1991] 

•  Binding  Concepts  Within  RPC  [SC21  N  5817,  Much  1991] 

•  Proposal  for  RPC  Service  Definition  and  Protocol  Specification  Parts  [SC21 N  5818, 
Much  1991] 

•  Modelling  Rationale  for  OSI  RPC  [SC21  N  5819,  Much  1991] 

•  Contribution  on  Computation  Model  [SC21  N  5821,  March  1991] 

•  Proposal  for  the  Use  ofXALS  in  the  Standardization  of  RPC  [SC21  N  5822,  March 
1991] 

•  Position  on  RPC  Context  Handles  [SC21  N  5823,  March  1991]. 

ISO  work  with  respect  to  RPC  includes  the  fallowing: 

•  Nature  of  the  OSI  RPC  Service  Boundary  and  Service  Provider  [SC21  N  5586, 
January  1991] 

•  Working  Definitions  for  Client  and  Server  [SC21 N  5590,  January  1991] 

•  Call  for  Comment  on  OSIRPCIDN  [SC21  N  5588,  January  1991] 

•  Mapping  Between  RPC  IDN  andASN.l  [SC21/WG6  N  1 199,  June  1992]. 

The  aim  of  the  current  work  in  ISO  on  RPC  is  to  provide  a  mechanism  for  writing 
distributed  applications  that  are  both  syntactically  and  semantically  similar  to  a  local  procedure 
call.47  The  scope  of  RPC  includes  a  language-independent  IDN  for  specifying  interfaces  between 
components  of  distributed  applications.  The  RPC  protocol  for  a  particular  interface  definition  is 
derived  from  die  IDN. 

RPC  is  closely  related  to  two  projects  in  SC22:  Common  Language  Independent  Data 
Types  (CUD)  (ISO  11404)  and  Common  Language  Independent  Procedure  Call  Mechanism 
(CLIP  or  CLDPCM)  (see  also  Section  4.3.1).  SC22/WG1 1  has  agreed  that  there  is  no  overlap 
between  the  CU  projects  and  RPC.  However,  there  should  be  cross  references  between  the 
standards.  The  CU  projects  identified  below  are  giving  an  abstract  definition  of  data  types  and 
procedure  call  mechanism,  while  RPC  is  a  concrete  definition  that  extends  the  procedure  calls  to 
the  distributed  environment  [Ref.  SC21  N  5583  1991]: 

•  CUD  defines  a  set  of  data  types,  independent  of  any  particular  programming  language 
specification  or  implementation.  The  set  should  be  rich  enough  so  that  all  common 
data  types  in  standard  programming  languages  and  service  packages  can  be  mapped 
onto  some  data  type  in  the  set  Hence,  the  CUD  standard  is  an  abstract  definition  of 
the  set  of  data  types  in  terms  of  the  values  a  data  type  can  take  and  some  of  the 
operations  that  are  valid  on  the  data  type.  The  ISO  RPC  standard  will  define  the  set  of 
data  types  it  supports,  including  the  presentation  of  values  of  these  data  types  when 
exchanged  in  parameters  of  a  remote  procedure  calL 


47  The  ISO  approach  to  RPC  could  be  a  probtan  for  Ada. 
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•  The  aim  of  CLIP  is  to  define  a  generic  model  for  procedure  call  semantics  and 
therefore  is  an  abstract  definition  of  a  procedure  call  mechanism.  ISO  RPC  aims  to 
extend  the  semantics  of  a  local  procedure  call  in  a  distributed  environment  and,  in 
particular,  that  the  RPC  be  semantically  and  syntactically  similar  to  a  local  procedure 
call 

It  is  not  at  all  clear  whether  remote  operations  (ISO  9072)  can  be  used  to  satisfy  RPC 
requirements  or  whether  collaborative  work  with  ITU-TS  will  be  conducted  for  RPC.  SC21/WG6 
has  identified  requirements  for  RPC  and  IDN  and  has  begun  coordination  of  these  requirements 
with  SC22/WG11  and  ITU-TS  SGVII.  [Ref.  SC21  N  4926  1990;  SC21  N  4928  1990] 

In  December  1992,  the  WG8  RPC  Group  proposed  a  liaison  to  SC22/WG11.  Specifically, 
it  requested  guidance  on  how  best  to  tackle  internationalization  in  the  RPC  IDN  and  for  experience 
and  advisability  of  reserving  terminal  symbols  in  programming  languages.  [Ref.  SC21/WG8  N  62 

1992]  ASN.l  may  not  be  adequate  as  a  basis  for  the  IDN,  even  if  extended  for  this  purpose. 
Some  requirements  for  the  IDN  identified  in  SC21/WG6  are  [Ref.  SC21 N  4767  1990]: 

•  Be  user  friendly  in  the  sense  that  an  applications  programmer  can  translate  from  the 
IDN  to  the  programming  language  of  choice  in  a  straightforward,  approximately  one- 
to-one  manner 

•  Be  usable  to  automatically  generate  language-specific  interfaces  that  support  procedure 
calls  using  the  RPC  service 

•  Be  usable  to  automatically  generate  the  programming  language-specific  procedure 
declarations  that  correspond  to  die  procedures  in  an  IDN  for  use  by  a  server. 

There  would  appear  to  be  some  danger  of  duplication  of  effort — and  possibly  even  rival 
standards — unless  RPC  is  brought  together,  in  some  manner,  with  ROSE.  [Ref.  OSN  1990e] 
For  example,  ROSE  has  already  standardized  an  IDN,  called  RO-notation,  that  uses  ASN.l  as  a 
language-independent  way  of  describing  the  data  types  of  the  parameters.  ROSE  is  already  used 
widely,  and  a  program  of  enhancements  to  allow  it  to  meet  additional  needs  is  underway. 
However,  ROSE  is  not  even  mentioned  in  the  new  RPC  work  item  proposal. 

The  UK  is  concerned  that  the  mapping  between  the  RPC  IDN  and  ASN.l  should  always 
produce  one  and  only  one  ASN.l  type  for  each  RPC  interface  type  definition.  This  is  essential  for 
the  correct  encoding  of  data  types.  Following  discussions  in  the  October  1992  RPC  Rapporteur 
meeting,  die  UK  updated  the  formal  mapping  rules  between  the  two  notations.  [Ref.  SC21  N  7614 

1993] 

The  Distributed  Office  Applications  Model  (DO AM)  standards  (ISO  10031)  have  been 
developed  assuming  the  support  of  ROSE.  In  a  January  1992  liaison  statement  to  SC21/WG6, 
SC18/WG4  SWG  on  DOA  requested  that  RPC  be  developed  in  a  manner  that  allows  applications 
in  die  DO  AM  framework  to  exploit  compliant  RPC  implementations  without  modification.  [Ref. 
SC21  N  6656  1992]  In  its  reply,  WG6  stated  that  use  of  RPC  by  existing  implementations  (e.g., 
of  an  application  in  the  DOAM  framework)  is  probably  not  technically  possible.  If  a  standard  is  to 
be  changed  to  use  RPC  rather  than  ROSE,  it  must  change  its  interface  notation  from  RO-notation  to 
the  RPC  IDN.  [Ref.  SC21  WG6  N  1 170  1992] 

Two  RPC  implementations  currently  exist:  Sun  RPC  and  OSF  RPC.  The  two  are  not 
mutually  exclusive,  and  the  key  issue  for  the  user  is  agreement  on  the  application  program  interface 
so  the  user  does  not  have  to  worry  about  differences  in  various  RPCs.  This  requires  a 
standardized  interface  definition  language  such  as  the  Network  Interface  Definition  Language 
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(NIDL),  which  was  developed  by  Apollo,  is  being  enhanced  by  Digital,  and  is  the  basis  of  an 
ANSI  recommendation  to  ISO.  [Ref.  OSN  1990g] 

9.11.3.6  User  Application  Service  Element 

A  new  ASE  is  emerging  from  development  of  the  Distributed  Transaction  Processing  (TP) 
standard  (ISO  10026),  just  as  RTSE  evolved  from  the  RTS  of  ITU-TS  X.410.  The  TP  protocol 
(ISO  10026-3)  does  not  provide  an  explicit  protocol  for  transmitting  user  data.  The  TP  service 
standard  (ISO  10026-2)  provides  a  service  (TP- DATA)  that  is  implemented  by  a  user  application 
service  element  (U-ASE).  The  TP  standards  specify  a  general  mechanism  that  allows  a  set  of 
programs  to  interact  in  a  controlled  manner  but,  because  of  its  generality,  it  was  not  possible  for 
the  standard  to  specify  what  data  would  flow  between  programs  (this  is  in  sharp  contrast  to  X.400, 
in  which  data  flows  were  standardized).  The  U-ASE  is  both  separate  from  and  part  of  the  TP 
program.  It  is  part  of  die  TP  program  because  it  is  crafted  to  encode  and  decode  its  data  stream — a 
U-ASE  made  for  a  specific  data  stream  is  useful  only  to  programs  that  need  that  data  stream.  It  is 
separate  from  a  program  because  it  can  be  used  by  many  programs.  A  TP  program  can  use  two 
different  U-ASEs  to  communicate  with  different  types  of  users.  [Ref.  IGOSS  1993] 

9.11.4  Message  Handling  System  (X.400) 

9.11.4.1  MHS  and  MOTIS  Overview** 

The  Message  Handling  Systems  (MHS)  standard  facilitates  the  exchange  of  all  kinds  of 
information  among  MHS  users  through  the  OSI  communication  system.  Although  MHS  uses 
mainly  interpersonal  messages,  the  MHS  service  may  be  also  used  to  exchange  business 
documents  and  others.  One  of  the  principle  features  of  MHS  is  its  operation  in  a  store-and- 
forward  manner  so  that  the  originator’ s  system  does  not  have  to  be  attached  to  the  recipient's 
system.  Instead,  the  message  may  be  routed  via  ooe  or  more  intermediate  systems. 

CCITT  (not  ITU-TS)  first  published  the  well  known  X.400  standard  in  1984.  Since  then, 
ITU-TS  and  ISO/IEC  have  worked  together  to  harmonize  their  activities  and  produced  parallel 
standards  with  almost  identical  text.  They  are  the  ITU-TS’s  X.400  (1988)  and  the  ISO/DEC  10021 
Message  Oriented  Text  Interchange  System  (MOTIS).  The  differences  between  the  X.400 
standard  and  the  MOTIS  standard  are  minor. 

The  1988  MHS  standard  (denoted  MHS-84)  contains  many  improvements  over  the  1984 
MHS  standards  (denoted  MHS-88).  These  improvements  include  the  use  of  user  friendly 
Directory  names  instead  of  user  unfriendly  originator/recipient  addresses  to  identify  MHS  users, 
the  use  of  distribution  lists  to  name  groups  of  recipients,  the  provision  of  security  services  that 
woe  practically  absent  in  MHS-84,  and  the  use  of  the  full  OSI  stack  for  compatibility  with  other 
OSI  system  software. 

A  User  Agent  (UA)  provides  access  to  the  Message  Transfer  Service  (MTS)  or  a  Message 
Store  (MS)  on  behalf  of  its  user.  It  submits  and  delivers  messages  for  its  user.  It  may  provide  text 
processing  facilities  for  the  composition  of  messages.  Some  UAs  are  specialized  to  handle  person- 
to-person  communication,  some  are  specialized  to  handle  business  documents,  and  others  are  for 
some  specialized  content  type.  In  general,  a  UA  can  only  process  a  certain  content  type. 
Currently,  only  two  content  types  have  been  standardized:  the  interpersonal  message  (IPM) 
content  type  and  the  Pedi  (edi  standing  for  electronic  data  exchange)  content  type.  An  EPM  content 

48  TUsMCtkm  has  been  excerpted  from  [T«ng  1991]. 
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type  is  used  for  person-to-person  communication,  while  a  Pedi  content  type  is  used  for  business 
trading.  Thus,  there  are  IPM-UAs  and  Pedi-UAs. 

9.11.4.2  Status  and  Relation  of  MHS  and  MOTIS  Standards 

Table  25  summarizes  the  set  of  standards  that  define  MHS  (X.400)  and  MOHS  (ISO/IEC 
10021)  services.  Efforts  made  by  the  ITU-TS  (formerly  CCITT)  and  ISO  to  converge  MHS  and 
MOTIS  resulted  in  1988  with  sets  of  standards  that  are  substantially,  but  not  completely, 
compatible.  [Balloting  for  the  previous  MOTIS  standards  (DIS  8505,  DIS  8883,  and  DIS  9065) 
was  suspended,  and  the  scope  of  these  standards  has  been  incorporated  in  ISO  10021.] 

The  relationships  of  the  X.400-1984,  X.400-1988/1992,  and  MOTIS  (1988  and  1992) 
standards  are  also  provided  in  Table  29.  Notice  that  MOTIS  still  has  no  parallel  to  the  X.408 
standards  for  algorithms  used  when  converting  between  different  types  of  encoded  information,  no 
parallel  for  the  X.430  (now  T.430)  Teletex  access  protocols,  and  none  for  X.403. 


Table  25.  Basa  Standards  for  MHS 


Layer 

X.400-1984 

X.400-1988  and 
X. 400-1992 

MOTIS 

7 

7 

X.400 

X.401 

X.400* 

ISO  10021-1 

7 

X.400 

X.402 

ISO  10021-2 

7 

N/A 

X.403b 

None 

7 

N/A 

X407 

IS0 10021-3 

7 

X.408 

X.408 

None 

7 

X.409 

X.208 

X209 

ISO  8824 

ISO  8825 

7 

X.410 

X218 

X219 

X228 

X229 

ISO  9066-1 

ISO  9072-1 

ISO  9066-2 

ISO  9072-2 

7 

X.411 

X411 

X.419® 

IS0 10021-4 
13010021-6® 

7 

N/A 

X413 

ISO  10021-5 

7 

X.420 

X420  (IPM) 

IS0 10021-7 

7 

X.430 

T.430 

None 

7 

N/A 

TBD  (new  in  1988) 
TBD  (new  in  1992) 
TBD  (new  in  1992) 

7  (ACSE) 

N/A 

X.217 

X.227 

ISO  8649 

ISO  8650 

6 

N/A 

X216 

X.226 

ISO  8622 

ISO  8823 

Source:  Provided  originally  by  OMN 

CON  in  September  1988. 

*1988  X.400  Senes  is  double-numbered  with  1988  F.400  Series. 

^Citation  for  X.403-1988  (and  X.403-1992)  includes  three  manuals. 
c1988  and  1992  X.419  and  ISO  10021-6  have  a  wider  scope  than  the  part  of 
1984  X.41 1  and  DIS  8883  that  they  replace. 

MHS  1988.  MHS  1988  provided  new  (relative  to  MHS  1984)  capabilities  for  message 
store  (listing,  summary,  fetching,  and  deletion  of  stored  messages);  security  services  (origin 
authentication,  secure  access  management,  data  confidentiality,  data  integrity,  nonrepudiation,  and 
security  management);  distribution  lists  (members,  submit  permission,  expansion  point,  and 
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owner);  directory  services  (authentication,  name  resolution,  data  list  expansion,  and  capability 
assessment);  physical  delivery  service  (basic  physical  rendition,  ordinary  mail,  physical 
forwarding,  and  return  of  undeliverable  mail);  and  conformance  testing  (methods,  criteria,  and 
notation).  In  addition,  MHS  1988  revised  MHS  1984  standards  for  naming,  addressing,  routing, 
and  special  access. 

MHS  has  been  extended  since  1984  to  include  voice,  EDI,  and  file  transfer  in  the  message 
body.  Also  many  bugs  in  the  specification  have  been  fixed. 

NIST  Special  Publication  500*182,  Guidelines  for  the  Evaluation  of  Message  Handling 
Systems  Implementations,  details  a  generic  process  that  helps  users  acquire  MHS.  The  guide 
advises  how  to  determine  the  best  MHS  for  electronic  mail  requirements,  and  how  to  identify 
potential  MHS  implementations.  Candidate  implementations  can  then  be  measured  against  function 
and  performance  factors,  and  rated.  [Ref.  CSL  1992,  p.  2] 

An  ISO/IEC/ITU-TS  Computer  Conferencing  Woridng  Document  is  now  in  Version  13. 

A  group  is  woridng  on  an  "asynchronous  group  communication"  standard  based  on 
X.400,  X.500,  and  DFR.  This  will  include  a  new  system  similar  to  but  more  sophisticated  than 
USENET  and  facilities  for  joint  editing  of  documents  and  voting/polli*">.  The  name  of  the  draft 
standard  is  currently  X.gc. 

The  MHS  1988  recommendations  were  supplemented  by  a  new  series  of  standards  on  the 
service  aspects  of  MHS.  These  ITU-TS  recommendations  are: 

•  F.400,  System  and  Service  Overview 

•  F.401 ,  Naming  and  Addressing  for  Public  Message  Handling  Services 

•  F.4 10,  The  Public  Messaging  Transfer  Sendee 

•  F.415,  Intercommunication  with  Public  Physical  Delivery  Services 

•  F.420,  The  Public  Interpersonal  Messaging  Service 

•  F.42 1 ,  Intercommunication  Between  the  IPM  Service  and  die  Telex  Service 

•  F.422,  Intercommunication  Between  die  IPM  Service  and  the  Teletex  Service. 

MHS  1992.  MHS  1992  revises  X.402,  X.411,  X.413,  X.419,  X.420.  and  X.435; 

there  are  major  additions  to  X.413  and  X.420.  Two  new  recommendations  are  included:  X.440, 
Voice  Messaging  System;  and  X.4xx,  MHS  Management  MHS  1992  enhancements  include  the 
following  [Ref.  PSC  1991]: 

•  File  transfer — allows  any  kind  of  files,  such  as  word  processing  documents, 
spreadsheets,  object  programs,  and  other  binary  files,  to  be  sent  via  X.400.  Closely 
aligned  with  ISO  8571  (FT AM),  MHS  1992  caters  to  store  and  forward  needs  rather 
than  direct  connection  file  transfer  intended  in  FT AM.  Rather  than  using  a  separate 
content  type,  file  transfer  in  MHS  1992  is  done  through  a  new  body  part  type,  which 
can  be  used  in  IPMS  and  EDI  content  types.  Transfer  of  binary  files  in  MHS  1992  is 
based  on  and  compatible  with  a  new  recommendation:  X.bft,  Binary  File  Transfer  for 
the  Telematic  Services.  T.bft  adds  a  capability  to  transfer  files  to  T.30  on  Group  3 
Facsimile  and  to  DTAM  protocols  (T.bft  is  technically  aligned  with  FTAM  but  with 
some  extensions  for  use  in  a  personal  computing  environment).  Transfer  syntax  may 
be  ASN.l  BER  or  as  specified  by  the  document  type.  Transfer  of  portions  of  a  file  or 
multiple  files  in  MHS  is  for  further  study.  Files  may  be  compressed  before  transfer, 
and  the  sender  may  request  how  the  data  being  transferred  is  to  be  used  in  relation  to 
files  to  be  stored  by  the  recipient  These  and  other  interoperability  parameters  for 
MHS  file  transfer  are  as  follows: 
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Content  type  parameter — indicates  the  abstract  data  types  of  the  contents  of  the 
file  and  the  structuring  information,  in  order  to  maintain  complete  file  structure 
and  semantics  during  transfer 

Compression  parameter — describes  the  compression  algorithm  by  specifying  the 
algorithm  identifier  and  algorithm  parameters 

Related  stored  file  parameter — indicates  to  the  recipient  any  intended  relationship 
(e.g.,  created,  replaced,  extended)  between  the  file  in  this  body  part  and  any 
file(s)  held  by  the  recipient 

File  attributes  parameter — carries  the  values  of  any  of  a  set  of  optional  file 
attributes  representing  a  request  to  the  recipient  to  use  these  values  if  a  new  file 
has  to  be  created  based  on  initial  file  attributes  (not  all  FT  AM  file  attributes  are 
included  in  MHS) 

Environment  parameter — describes  the  environment  (e.g.,  machine,  operating 
system,  application)  from  which  the  file  originated 

Extensions  parameter — conveys  the  information  not  accommodated  by  the  other 
parameters  of  file  transfer  body  part  (has  the  same  syntax  and  usage  as  that  for  die 
IPM  content  type  extensions  field) 

•  Notifications — provides  consistency  with  PI  Delivery  notifications:  IPMS  to  IPMS, 
IPMS  to  telematic  AUs,  and  IPMS  to  facsimile 

•  Accounting — permits  originator,  on  message  submission,  to  specify  reverse  charging 
on  a  per  recipient  basis;  uses  the  MHS  1988  extension  field  mechanism  to  specify  a 
parameter  to  say  the  percentage  to  be  charged  to  the  recipient  (e.g.,  0  percent);  applies 
only  to  messages  and  is  critical  for  submission,  which  means  that  systems  that  do  not 
understand  the  extension  or  that  do  not  support  the  type  of  charging  requested  will 
reject  the  submission  of  the  message 

•  Auto-submitted  Indication — allows  the  originator,  or  enables  the  User  Agent  or 
Message  Store,  to  indicate  to  the  recipient  whether  the  message  was  or  was  not 
automatically  submitted  by  a  machine  without  either  the  direct  or  indirect  human 
control  over  the  submission  and  to  determine  the  nature  of  the  submission;  values  are 
not  auto-submitted,  auto-generated,  auto-replied,  and  a ^to-forwarded  (absence  of  this 
indication  reveals  no  information  as  to  whether  or  not  the  message  submission 
involved  human  control) 

•  P22  Extensions — augments  extension  “buckets”  provided  by  MHS  1988  to  include 
new  per-recipient  heading  fields  and  new  notifications  for  the  P22  (IPM)  protocol, 
allowing  for  future  extensions  but  does  not  include  any  such  actual  extensions  and 
retaining  the  existing  P22  content  type  in  a  way  that  permits  backward  compatibility. 

9.11.4.3  Options  for  MHS 

Definition  of  interoperability  parameters  (see  Appendix  A)  for  use  of  MHS  will  require 
agreement  on  a  number  of  options.  The  choice  of  such  options  can  lead  to  multiple  profiles. 
Example  options  are  the  following,  in  which  there  are  suboptions  defined  by  choice  of  X 
(interpersonal  messaging  user  agent  or  electronic  data  interchange  user  agent,  each  with  or  without 
the  requirement  for  a  secure  agent);  Y  (basic  message  store  or  secure  message  store);  and  G  (an 
ADMD  gateway  capability  is  or  is  not  required)  [Ref.  IGOSS  1993): 

•  1988  relay  MTAfG] 

•  1988  end  system  in  which  the  MTA  is  collocated  with  a  1988  interpersonal  message 
UA,  an  electronic  data  interchange  UA,  or  both  [X,  G] 

•  An  end  system  in  which  an  MS  and  a  UA  are  collocated  with  the  MTA  [X,  Y,  G] 

•  An  end  system  in  which  an  MS  is  collocated  with  the  MTA  [Y] 

•  A  remote  UA  that  is  collocated  with  an  MS  [X,  Y] 
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•  A  remote  UA  that  does  not  require  MS  services  [X] 

•  A  remote  UA  that  does  require  MS  services  [X] 

•  A  remote  MS,  which  serves  a  remote  UA  [Y]. 

A  number  of  security  classes  may  be  defined  for  the  Message  Transfer  System  (MTS). 
These  may  include  implementing  all  security  mechanisms  outside  the  MTS  (e.g.,  within  the  UA  or 
MS);  implementing  most  security  mechanisms  outside  the  MTS  but  providing  in  die  MTS  services 
related  to  secure  access  management;  and  providing  authentication  and  non-repudiation  within  the 
MTS.  Each  of  the  above  example  classes  could  be  required  to  support  end-to-end  confidentiality, 
thus  defining  suboptions.  [Ref.  IGOSS  1993] 

9.11.4.4  Profiles  and  for  MHS 

The  following  shows  the  current  status  of  MHS  ISPs: 

•  DISP  10611-1,  ISPs  AMHln  -  Message  Handling  Systems  -  Common  Messaging, 
Parti:  Service  Support,  1993 

•  DISP  10611-2,  ISPs  AMHln  -  Message  Handling  Systems  -  Common  Messaging, 
Part  2:  Specification  of  ROSE,  RTSE,  ACSE,  Presentation,  and  Session  for  Use  by 
MHS,  1993 

•  DISP  10611-3,  ISPs  AMHln  -  Message  Handling  Systems  -  Common  Messaging, 
Part  3:  AMH11:  Message  Transfer  (PI),  1993 

•  DISP  10611-4,  ISPs  AMHln  -  Message  Handling  Systems  -  Common  Messaging, 
Part  4:  AMH12:  MTS  Access  (P2),  1993 

•  DISP  1061 1-5,  ISPs  AMHln  -  Message  Handling  Systems  -  Common  Messaging, 
PartS:  AMH13:  MS  Access  (P7),  1993 

•  DISP  1 1 189,  ISP  FDI2  -  MHS  Use  of  Directory,  1993. 

DISP  11189  specifies  that  the  following  functions  be  used  to  access  Directory  services  for 
UAs  [Ref.  IGOSS  1993]: 

•  Verify  the  existence  of  a  Directory  Name 

•  Return  the  originator/recipient  address(es)  that  correspond  to  a  Directory  Name 

•  Determine  whether  a  Directory  Name  presented  denotes  a  user  or  a  Distribution  List 

•  Return  the  members  of  a  Distribution  List 

•  Return  the  capabilities  of  the  entity  referred  to  by  a  Directory  Name  (e.g.,  in  support  of 
a  particular  body  part) 

•  Return  the  public  key  or  certificate  referred  to  by  a  Directory  Name. 

9.11.4.5  Common  MHS  Message  Format  for  NATO  (ACP  123) 

Overview.  Beginning  in  May  1990,  subject  matter  experts  from  many  nations  met  to 

develop  a  common  messaging  strategy  that  can  be  deployed  to  facilitate  interoperability  among  the 
Allies.  The  strategy,  which  will  include  the  definition  of  a  new  Common  Message  Format  (CMF) 
and  corresponding  procedures,  is  to  be  based  on  X.400.  The  end  goal  is  to  replace  the  existing 
messaging  system  currently  based  on  the  Allied  Communications  Publication  127  (ACP  127)  and 
associated  documentation  (i.e.,  ACP  117  and  ACP  121).  (ACPs  are  meant  for  use  in  NATO  and 
other  nations  such  as  Australia  and  New  Zealand.)  The  X.400-based  ACP  will  be  called 
ACP  123.  Major  work  has  been  completed  in  the  area  of  requirements,  and  some,  but  not  all, 
procedural  issues  have  been  resolved.  The  new  standard  will  satisfy  not  only  the  ACP  127 
requirements,  but  also  national  requirements  such  as  the  US  Joint  Army,  Navy,  Air  Force 
Publication  (JANAP)  128  message  requirements.  The  work  will  use  the  MMHS  work  of  the 
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TSGCE  SG9,  including  the  mappings  between  ACP  127  and  X.400  that  have  been  defined  in  draft 
STANAG  4406  (see  Section  17.3.4.2).  (Ref.  ACP  123  1991] 

ACP  127.  Allied  Communications  Publication  (ACP  127)  is  a  message  formatting 
standard  commonly  used  by  Allied  nations.  Derivatives  of  it — ACP  126  and  Joint  Army,  Navy, 
Air  Force  Publication  (JANAP)  128  are  also  in  common  use.  ACP  117  and  ACP  121  are 
associated  procedural  documents.  ACP  123  was  selected  as  the  designation  for  the  new  X.400- 
based  military  messaging  system. 

AMH-ISME.  Allied  Message  Handling  (AMH)  International  Subject  Matter  Expert 
(ISME)  meetings  were  conducted  in  May  1990  and  March  1991  with  the  following  goals: 

•  Develop  a  common  messaging  strategy  that  can  be  deployed  to  facilitate 
interoperability  among  the  Allies 

•  Include  definitions  of  common  message  formats  (CMFs)  and  corresponding  sets  of 
procedures  based  on  X.400- 1988 

•  Replace  the  existing  messaging  systems  currently  based  on  ACP  127  and  its  associated 
documents  (ACP  1 17  and  ACP  121). 

ACP  123  Task  Force.  The  US  DoD  Defense  Communications  Agency  (now  DISA) 
initiated  in  July  1990  an  ACP  123  Task  Force  to  become  the  focal  point  for  developing  the  X.400- 
based  ACP  123  for  the  United  States.  One  product  of  this  group  was  the  ACP  Requirements 
Document  (Ref.  ACP  123  1991],  which  specifies  the  ACP  127  and  JANAP  128  message 
requirements  on  a  line-by-line  basis  and  provides  recommendations  on  how  those  requirements 
might  be  implemented  using  existing  or  newly  defined  X.400  services.  Their  work  is  being 
conducted  under  the  auspices  of  the  Defense  Message  System  (DMS). 

Modern  Message  Handling.  A  Modem  Message  Handling  working  group  met  in 
October  1991  and  January  1992  to  address  ACP  123  requirements.  Initial  meetings  of  this 
working  group  were  held  at  NACISA.  SHAPE  supported  this  working  group  in  1991  and  1992, 
but  SHAPE  support  for  ACP  123  ended  in  1992  when  the  reorganization  (downsizing)  of  SHAPE 
beginning  in  January  1993  did  not  contain  tasking  on  ACP  123.  [Ref.  Lawn  1994] 

Content  of  ACP  123.  ACP  123  has  three  chapters  and  several  annexes.  The  annexes 
address  ASN.l  definitions  and  object  identifiers.  The  three  chapters  address  the  following: 

( 1 )  Introduction  and  definition  of  terms  and  abbreviations 

(2)  Common  elements  of  service,  X.400  elements  of  service,  and  military  extensions 

(3)  MHS  components  (e.g.,  MTS,  UA,  MS);  procedures;  security;  naming  and 
addressing;  and  management. 

9.11.5  Manufacturing  Message  Specification  (MMS) 

9.11.5.1  MMS  Standards  and  Relation  to  MAP 

A  Manufacturing  Message  Specification  (MMS)  has  been  defined  to  provide  for  client- 
server49  message-based  communications  between  programmable  devices  in  a  computer-controlled 
environment  (Ref.  IGOSS  1993].  MMS  is  the  key  component  of  the  Manufacturing  Automation 
Protocol  (MAP),  the  OSI  protocol  promoted  worldwide  by  General  Motors,  now  in  Version  3.O.50 


49  The  clicm-scrvcr  roles  arc  MMS-servicc  specific  The  client  is  the  system  that  exercises  control,  and  the  server 
is  the  system  being  controlled.  A  device  may  provide  support  services  of  client,  server,  or  both. 

50  MAI’  is  associated  with  another  standard.  Technical  Office  Protocol  (TOP)  (see  Section  15.1.3.6). 
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MMS  was  originally  developed  as  Electrical  Institute  of  America  (EIA)  RS-511  [Ref.  INI  1987]. 
The  MMS  standatd  has  four  parts: 

•  ISO  9906-1,  Manufacturing  Message  Specification,  Part  1:  Service  Definition 
•.  AM  1:  Data  Exchange,  1993 

•  ISO  9506-2,  Manufacturing  Message  Specification,  Part  2:  Protocol  Specification 

AM  1:  Data  Exchange,  1993 

•  ISO  9506-3,  Manufacturing  Message  Specification,  Part  3:  Companion  Standard  for 
Robotics 

•  JSO  9506-4,  Manufacturing  Message  Specification,  Part  4:  Companion  Standard  for 
Numerical  ControL 

The  MMS  standard  defines  86  different  messaging  services.  Example  (all  required  in  IGOSS)  are 
initiate,  conclude,  abort,  reject,  and  identify.  Both  IGOSS  and  MAP  3.0  (see  Section  15.1.3.6) 
define  implementation  classes  of  services,  in  which  Class  0  comprises  the  five  services  identified 
above.  While  MMS  is  a  standard  primarily  used  for  industrial  automation,  it  is  included  because 
its  wide  use  may  affect  some  military  message  standards.  Section  9.13.6  discusses  the  time- 
critical  communications  requirements  of  MAP. 

The  MMS  work  in  ISO  is  under  TC184/SC5/WG1,  which  is  responsible  for 
communications  systems  in  the  area  of  industrial  automation.  [Ref.  Kirk  1990]  In  1989,  a  new 
work  item  to  develop  an  international  standard.  Framework  for  CIM  Systems  Integration,  was 
assigned  to  SC5/WG1.  Efforts  are  focused  on  ENV  40  003  based  on  the  CIM-OSA  work  from 
the  European  Strategic  Programme  of  Research  and  Development  in  Information  Technology 
(ESPRIT).  MMS  is  included  in  IGOSS  (see  Section  16.1.3.3). 

9.11.5.2  MMS  Overview51 

MMS  uses  object  oriented  methodology  to  model  the  items  and  entities  required  for 
communication  among  manufacturing  devices.  MMS  services  operate  on  MMS  objects.  An  object 
model  is  specified  for  the  various  components  of  an  MMS  environment:  Virtual  Manufacturing 
Devices  (VMDs),  domains  within  VMDs,  program  invocations  within  VMDs,  variables  and  data 
within  VMDs,  and  several  others.  MMS  objects  are  built  from  attributes  and  constraints 
(Figure  13). 

MMS  uses  the  client/server  approach  to  distribute  services  across  devices  on  die  network. 
Typically,  the  client  is  a  host  computer  and  die  server  is  some  factory  floor  device. 

MMS  is  unique  among  the  OSI  application  standards  due  to  companion  standards. 
Companion  standards  allow  MMS  to  provide  additional  detail  focused  on  a  particular  type  of 
factory  floor  device.  The  companion  standard  mechanisms  are  inherent  throughout  the  base  MMS 
specification.  .For  example,  53  of  the  86  MMS  services  are  specifically  designed  for  extension. 
Additionally,  8  of  the  18  MMS  objects  are  specifically  designed  for  extension.  For  example,  the 
MMS  companion  standard  for  robots  provides  a  description  of  a  robot  arm  object.  This 
description  then  becomes  an  extension  of  the  base  VMD  object  A  companion  standard  can  add  to 
the  base  MMS  specification  the  following  items:  specification  of  extra  parameters  in  die  service 
primitives,  specification  for  additional  detail  attributes  in  MMS  object  definitions,  and  additions  to 
the  protocol  procedures  and  the  protocol  behavior. 

51  This  section  hat  been  excerpted  Cram  [Tang  1991], 
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Figur*  13.  Structure  of  Object*  for  MMS 

9.11.6  File  Transfer,  Access,  and  Management  (FTAM) 

Both  FTAM  and  MHS  (ITU-TS  X.400)  (see  Section  9.11.4)  can  be  used  for  carrying 
many  fonns  of  messages.  Where  an  X.400  MHS  is  already  in  place  and  the  destinations  may  not 
always  be  on  line,  X.400  (1988)  with  a  message  store  may  be  the  best  option.  Where  there  is  a 
requirement  for  heavy  traffic  or  immediate  transfer  and  acknowledgment,  FTAM  may  be  the  better 
solution.  [Ref.  OSN  1992a] 

NIST  Special  Publication  500-196,  Guidelines  for  the  Evaluation  of  File  Transfer,  Access 
and  Management  Implementations  helps  users  acquire  FTAM  implementations  [Ref. 
CSL  1992,  p 2]  just  as  NIST  SP  500-182  does  for  MHS  implementations  (see  Section  9.1 1.4). 

9.11.6.1  FTAM  Overview52 

File  handling  is  one  of  the  principal  services  in  a  networking  environment  Many  existing 
file  protocols  are  concerned  primarily  with  moving  complete  files.  The  File  Transfer  Access 
Management  (FTAM)  standard,  which  is  specified  in  ISQ/IEC  8571,  has  broadened  the  scope  of 
these  protocols  by  offering  three  modes  of  file  manipulation:  file  transfer,  file  access,  and 
file/filestore  management  Hie  transfer  is  the  movement  of  a  complete  file  between  two  filestores 
in  different  open  systems.  Hie  access  performs  reading,  writing,  or  deleting  of  selected  parts  of  a 
remote  fife.  Hfe/filestore  management  refers  to  the  management  of  a  remote  file/fifestore. 

Organization  of  a  fife  is  operating-system  specific — a  fife  may  be  considered  a  sequence  of 
bytes  in  one  system  and  a  series  of  records  in  another.  In  order  to  accommodate  heterogeneous  fife 
systems,  die  FTAM  standard  introduces  the  concepts  of  a  virtual  file  and  a  virtual  filestore.  Virtual 
files  and  virtual  filestores  are  the  OSI  abstractions  of  real  files  and  real  filestores.  The  use  of 
virtual  fifes  and  virtual  filestores  permits  applications  to  perform  file  operations  over  a  variety  of 
fife  types  without  detailed  knowledge  of  the  characteristics  of  the  remote  fife  systems.  Since  virtual 
filestores  and  virtual  fifes  are  only  abstractions,  an  FTAM  implementation  needs  to  provide 
translation  between  virtual  files  and  system-specific  files. 

52  Portions  of  this  section  have  been  excerpted  from  [Tang  1991], 
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FTAM  is  an  asymmetric  protocol  involving  two  objects:  an  initiator  and  a  responder.  An 
initiator  initiates  an  application  association  with  a  responder  for  its  subsequent  file  activities,  while 
a  responder  maintains  a  virtual  filestore  containing  virtual  files  that  are  the  subjects  of  file  activities 
by  different  initiators.  The  initiator  is  normally  invoked  by  a  local  user's  request  and  supplied  with 
information  about  a  local  file  and  a  remote  virtual  file.  The  responder  is  informed  of  the  file 
operations  through  the  PDUs  exchanged  with  the  initiator. 

The  term  FTAM  dialogue  is  used  to  qualify  the  application  association  between  an  initiator 
and  a  responder.  It  is  possible  that  the  same  responder  maintains  more  than  one  FTAM  dialogue, 
or  the  same  initiator  maintains  more  than  one  FTAM  dialogue.  An  initiator  or  a  responder 
identifies  a  role  of  an  application  entity  for  an  FTAM  dialogue.  The  same  entity  can  simultaneously 
play  different  roles  for  different  FTAM  dialogues. 

9.11.6.2  FTAM  Standards 

FTAM  defines  a  file  service  and  specifies  a  file  protocol  within  die  Application  Layer 
(Layer  7).  The  standard  is  concerned  with  identifiable  bodies  of  information  that  can  be  treated  as 
files,  which  may  be  stored  within  open  systems  or  passed  between  application  processes. 
ISO  8571  defines  the  basic  file  service  for  FTAM.  It  provides  sufficient  facilities  to  support  file 
transfer  and  establishes  a  framework  for  file  access  and  file  management  This  standard  does  not 
specify  the  interfaces  to  a  file  transfer  or  access  facility  within  the  local  system.  An  addendum  may 
be  added  that  reflects  quality  of  service  developments  and  integration.  The  FTAM  standard 
currently  has  five  parts  with  amendments  and  addenda.  Addendum  1  (Filestore  Management) 
defines  a  hierarchical  file  system  with  subdirectories,  links,  paths,  etc.  An  additional  standard 
describes  a  performance  test  suite.  Second  editions  to  die  FTAM  standard  (Parts  1-5)  are 
underway.  The  pertinent  FTAM  standards  are: 

•  ISO  8571-1  (Part  1):  General  Introduction,  1988 

AM  1,  Filestore  Management,  December  1992 

AM  2,  Overlapped  Access,  August  1993 

AM  3,  Service  Enhancement,  December  1993 

WDAM  4,  Security  Enhancement  (project  suspended  July  1993) 

WD  8571-1  (Part  1):  General  Introduction,  Edition  2  (incorporates  AM  1),  1992 

•  ISO  8571-2  (Part  2):  Virtual  Filestore  Definition 

AM  1,  Filestore  Management,  December  1992 
AM  2,  Overlapped  Access,  August  1993 

PD  AM  3,  Enhancement  for  FTAM  Services  to  Satisfy  Additional  User 
Requirements  (project  suspended  as  1993  PDAM  has  null  content)- 
WDAM  4,  Security  Enhancement  (project  suspended  July  1993) 

WD  8571-2  (Part  2):  Virtual  Filestore  Definition,  Edition  2  (incorporates  AM  1), 
1992 

•  ISO  8571-3  (Part  3):  File  Service  Definition 

AM  1,  Filestore  Management,  December  1992 
AM  2,  Overlapped  Access,  August  1993 
AM  3,  Service  Enhancement,  December  1993 

WDAM  4,  Enhancement  to  FTAM  Security  Services  (project  suspended 
July  1993) 

WD  8571-3  (Part  3):  File  Service  Definition,  Edition  2  (incorporates  AM  1), 
1992 
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•  ISO  8571-4  (Part  4):  File  Protocol  Specification 

AM  1,  Filestore  Management,  December  1992 
AM  2,  Overlapped  Access,  August  1993 

-  AM  3,  Service  Enhancement,  December  1993 
AM  4,  Defect  Report  Changes,  November  1992 

WDAM  5,  Enhanced  Security  for  FTAM  (project  suspended  July  1993) 

WD  8571-4  (Part  4):  File  Protocol  Specification,  Edition  2  (incorporates  AM  1), 
1992 

•  ISO  8571-5  (Part  5):  PICS  Proforma,  December  1990 

FDAM  1,  Filestore  Management,  July  1992  (editing  meeting  January  1994) 
WDAM  2,  Overlapped  Access  (in  the  absence  of  a  new  WD,  SC21  proposed  in 
July  1993  to  reassess  this  project) 

WDAM  3,  Enhancement  to  FTAM  Services  to  Satisfy  Additional  User 
Requirements  (to  be  progressed  as  a  technical  corrigendum) 

WDAM  4,  Enhancement  to  FTAM  Security  Services  (project  suspended 
July  1993) 

WD  8571-5  (Part  5):  Protocol  Implementation  Conformance  Statement 
Proforma,  Edition  2  (rapporteur  meeting  January  1994) 

•  Conformance  Test  Suite  for  the  FTAM  Protocol  has  the  following  parts: 

ISO/IEC  10170-1  (Part  1):  Test  Suite  Structure  and  Test  Purposes,  January  1993 
[SC21N7530] 

WD  10170-2  (Part  2):  FTAM  Abstract  Test  Suite  (CD  expected  October  1994; 
however,  this  project  risks  cancellation  by  SC21  in  the  absence  of  written 
confirmation  that  the  regional  workshops  will  provide  a  WD  by  June  1994.  [Ref. 
SC21N  7728  1993]) 

•  WD  10170-3  (Part  3):  ACSE  Abstract  Test  Suite  Embedded  Under  FTAM  (CD 
expected  October  1994) 

-  WD  101704  (Part  4):  Presentation  Abstract  Test  Suite  Embedded  Under  FTAM 
(CD  expected  October  1994) 

WD  10170-5  (Part  5):  Session  Abstract  Test  Suite  Embedded  Under  FTAM  (CD 
expected  October  1994). 

The  current  FTAM  standard  treats  a  filestore  as  an  unstructured  collection  of  files. 
Amendment  1  defines  a  structured  filestore  to  allow  the  organization  and  manipulation  of  individual 
groups  of  files.  Amendment  2  on  Overlapped  Access  allows  more  efficient  access  to  contents  of  a 
structured  file.  The  Overlapped  Access  draft  specification  uses  the  formal  description  language 
LOTOS.  These  extensions  will  support  needs  of  the  Network  Hie  Store,  but  harmonization  with 
Document  Transfer  and  Manipulation  (DTAM)  (ITU-TS)  and  Document  Filing  and  Retrieval 
(DFR)  (SC  18)  will  be  needed.  PICS  proformas  such  as  ISO  8571-5  provide  a  framework  for 
specifying  compliance  with  all  the  interoperability  parameters  for  the  implementation  of  a  protocol; 
this  concept  is  discussed  in  Section  12.2.2. 

In  order  to  cope  with  the  wide  range  of  possible  file  mechanisms,  FTAM  uses  a  virtual 
filestore  model  In  FTAM's  virtual  filestore  model  files  are  structured.  Each  file  has  a  set  of 
attributes  (e.g.,  owner  information  and  contents  type),  in  addition  to  the  data  association  with  the 
file.  The  contents  type  of  the  file  defines  the  file  structure.  Currently  FTAM  is  not  easily 
exportable  to  other  application  services.  The  new  work  will  attempt  to  improve  efficiency  by 
reducing  the  number  of  confirmed  requests  (e.g.,  needed  for  file  transfer  over  long-haul 
communications);  extending  and  simplifying  FTAM  services  to  allow  other  applications  services 
(e.g.,  TP)  to  easily  use  FTAM  providing  services  (e.g.,  for  data  transfer)  with  minimum  overhead 
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by  providing  high-level  services;  and  providing  file  services  for  other  user  services,  such  as  ITU- 
TS  telematic  services. 

WGS,  repotting  on  the  status  of  ISO  8571-2/DAM  3  in  May  1992,  raised  the  following 

issues: 

•  An  international  Registration  Authority  for  Objects  does  not  yet  exist 

•  Additional  document  types  are  under  development  that  may  need  to  be  incorporated  in 
8571-2  as  part  of  this  project 

•  Additional  generalized  constraint  sets  (file  structure)  are  under  development  that  may 
need  to  be  incorporated  in  8571-2  as  part  of  this  project 

As  these  issues  have  yet  to  be  resolved,  WG5  believes  that  the  project  is  still  active. 
[Ref.  SC21  N  7162  1992] 

As  a  consequence  of  the  proliferation  of  FT AM  implementations  over  the  past  few  years, 
the  document  types  included  in  the  base  standard  are  not  sufficient  for  the  wide  variety  of 
applications  served  by  FTAM.  For  example,  new  document  types  for  CGM,  EDI,  and  COBOL 
have  been  submitted  to  the  FTAM  Group  for  comment  and  review.  The  FTAM  group  believes  that 
ISO  should  set  up  an  International  Document  Type  Registry  where  the  already  defined  document 
types  can  be  held  and  publicized.  Moreover,  ISO  should  set  up  a  mechanism  to  manage  the 
document  types  that  involve  those  ISO  Groups.  [Ref.  SC21  N  6229  1991] 

In  addition,  some  existing  document  types  include  optional  facilities  that  have  led  to 
interoperability  problems.  It  was  therefore  proposed  in  June  1991  that  document  type  definitions 
include  a  statement  of  conformance  requirements.  This  information  could  be  included  as  Annex  F 
to  ISO  8571-2  or  as  a  Tutorial  Addendum  on  Interoperability  in  ISO  8571.  [Ref.  SC21  N  6230 
1991] 

SC21/WG5  is  developing  a  document  type  to  enable  FTAM  to  transfer  CGM  files  as  a 
structured  file  rather  than  (with  current  FTAM)  as  a  transparent  sequence  of  octets.  The  new  work 
would  provide  access  to  die  whole  metafile,  to  the  metafile  descriptor,  or  to  die  individual  pictures 
with  an  associated  metafile  descriptor.  All  three  CGM  encoding  techniques  would  be  supported: 
binary,  clear  text,  and  character  text  [Ref.  SC  21  N  4192  1989]  The  FTAM  Rapporteur  Group 
reviewed  the  latest  version  of  the  CGM  document  type  in  May  1991,  found  it  technically 
satisfactory,  and  recommended  that  it  be  registered  following  the  Procedures  for  the  Registration  of 
Document  Types  (ISO  9834,  Part  2).  [Ref.  SC21  N  6225  1991] 

In  May  1991,  SC21 WG5  proposed  an  EDIFACT/FTAM  Document  Type  (see  also  Section 
7.1.4)  in  an  attempt  to  merge  existing  FTAM  implementations  with  existing  EDI  systems  with  a 
minimum  of  change.  [Ref.  SC21  N  6224  1991]  DAM  3,  Service  Enhancement  to  ISO  8571-2, 
FTAM  Virtual  Filestore  Definition,  includes  the  CGM  and  EDIFACT  document  types. 

In  August  1991,  a  new  work  item  (NWI)  on  die  Definition  of  a  New  FTAM  Document 
Type  for  Directory  was  proposed  to  define  an  FTAM  document  type  that  represents  Directory 
information,  which  would  be  used  when  FTAM  is  transferring  Directory  information.  The  NWI 
failed  to  qualify  for  acceptance  to  the  Program  of  Work. 

Since  the  rejection  of  this  NWI  for  an  FTAM  Document  Type,  several  new  developments 
have  occurred.  The  first  is  a  NWI  proposal  for  a  Generic  ASN.l  Document  Type,  which  would 
allow  an  exact  mapping  of  any  ASN.l  defined  body  of  information  to  be  transferred  by  FTAM 
without  the  need  of  additional  specification.  The  second  is  the  rapid  progression  of  the  “Enhanced 
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Services”  amendment  to  FT AM  whose  main  purpose  was  specifically  to  allow  FT AM  to  be  easily 
utilized  by  other  ASEs.  [Ref.  SC21/WG8  N  63  1992] 

At  the  SC21  Plenary  in  May  1992,  the  UK  proposed  a  new  work  item  on  a  Class  of 
Mappings  from  a  Single  ASN.l  Type  to  an  FTAM  Document  Type.  The  proposal  was  for  a  new 
part  of  the  FTAM  standard  to  specify  a  generic  FTAM  Document  Type.  This  type  would  be  used 
to  define  arbitrarily  many  specific  FTAM  Document  Types  by  supplying  only  an  ASN.l  type 
definition  and  an  ASN.l  Object  Identifier  to  identify  the  resulting  FTAM  Document  Type.  The 
resource  requirements  necessary  to  forward  this  proposed  NP  to  JTC1  for  letter  ballot  were  not 
met  (Le.,  at  least  five  national  bodies  willing  to  actively  participate).  Therefore,  this  Proposed  NP 
was  returned  to  SC21.  [Ref.  SC21  N  7443  1992] 

In  March  1992,  the  United  States  noted  the  following  problem  with  certifying  FTAM 
implementations  as  conformant  Some  OSI  certification  agencies  will  not  certify  FTAM 
implementations  as  conformant  when  the  implementation,  in  the  role  of  an  initiator,  does  not 
employ  all  possible  protocol  variations,  even  though  the  protocols  that  are  used  completely  support 
the  services  of  the  implementation.  It  follows  that  the  appropriate  standards  should  be  clarified  so 
as  to  allow  the  certification  agencies  to  deselect,  within  permitted  bounds  as  defined  by  the 
standard,  tests  that  exercise  protocols  not  used  to  support  the  claimed  services  of  the  product 
Although  the  problem  presently  concerns  FTAM,  it  may  occur  in  products  implementing  other 
standards  where  there  is  an  asymmetric  i  Ttionship  between  correspondents  and  where  die  initiator 
controls  die  protocol  that  will  be  hanged.  [Ref.  SC21  N  6802  1992] 

EWOS  is  developing  a  Re*,  ote  Action  (RA)  service  and  protocol  for  use  with  FTAM  to 
support  the  ability  to  perform  a  remote  action  upon  completion  of  a  file  operation.  Examples  of  a 
remote  action  would  be  execution  of  a  batch  job  that  is  transferred  to  another  system  via  FTAM  and 
to  spool  a  print  file  to  a  printer  after  being  transferred  using  FTAM.  Both  RFC  and  JTM  could 
provide  this  support,  but  JTM  is  viewed  in  EWOS  as  too  complex  for  simple  remote  actions.  RA 
would  not  compete  with  JTM  and  specifically  would  not  support  such  JTM  services  as  gathering 
information  for  input  to  a  job,  spawning  jobs  to  several  systems,  manipulating  entries  in  job 
queues  (e.g.,  kill  a  job),  monitoring  progress  of  jobs,  or  preparing  progress  reports.  [Ref.  EWOS 
1990] 

The  FTAM  standards  include  an  annex.  Commitment  Control  with  File  Transfer,  which 
defines  a  specific  example  of  how  FTAM  could  be  used  with  CCR.  This  was  originally  developed 
when  CCR  was  at  DIS  status.  In  response  to  an  earlier  defect,  this  annex  was  suspended  until 
CCR  restabilized.  Following  the  publication  of  CCR,  an  input  document  was  drafted  to  replace  the 
old  annex.  During  the  process  of  drafting  the  annex,  it  became  apparent  that  while  FTAM  can 
recover  from  an  application  or  communication  failure  during  data  transfer,  CCR  treats  a  failure 
before  the  end  of  Phase  I  as  a  (presumed)  rollback.  This  relation  between  FTAM  recovery  and 
CCR  recovery  requires  careful  examination.  [Ref.  SC21 N  6228  1991] 

9.11.6.3  Options  for  FTAM 

Definition  of  interoperability  parameters  (see  Appendix  A)  for  use  of  FTAM  will  require 
agreement  on  a  number  of  options.  The  choice  of  such  options  can  lead  to  multiple  profiles.  An 
example  is  the  choice  of  positional  file  transfer,  management,  and  simple  file  access— all  three  are 
required  in  IGOSS  (see  Section  16.1.3.3)  but  not  in  other  profiles.  In  addition  the  documents 
supported  need  to  be  specified  in  a  profile. 
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9.11.6.4  Profiles  for  FTAM 

The  ISO  FTAM  standard  (ISO  8571-2,  Annex  B)  provides  for  three  document  types: 
unstructured  text,  sequential  text,  and  unstructured  binary.  OIW  Stable  Implementor's  Workshop 
agreements  have  been  published  by  NIST  for  four  others:  sequential  file,  random  access  file, 
indexed  file,  and  file  directory  file.  Six  implementation  profiles  have  been  defined  by  the  European 
Standards  Promotion  and  Application  Group  (SPAG),  which  have  the  following  corresponding 
profiles  from  the  NIST  OSI  Implementor's  Workshops: 

•  Sw^pfe  Fife  Transfer  (SPAG  A/111,  NISTT1.ENV  41  204) 

•  Positional  File  Transfer  (SPAG  A/112,  NIST  T2,  ENV  41  206) 

•  Full  File  Transfer  (SPAG  A/1 13,  NIST  T3) 

•  Simple  File  Access  (SPAG  A/122,  NIST  Al) 

•  Full  File  Access  (SPAG  A/123,  NIST  A2) 

•  Management  (SPAG  A/13,  NIST  Ml). 

International  Standardized  Profiles  (ISPs)  are  finalized  by  regional  workshops  and 
submitted  for  ISO  acceptance  by  the  JTC1  Special  Group  on  Functional  Standardization  (SGFS). 
There  are  currently  six  parts  to  ISQ/IEC  10607  and  one  part  to  DISP  1 1 190  on  FTAM  ISPs: 

•  ISQ/IEC  ISP  10607-1,  ISPs  AFT  nn  -  File  Transfer,  Access,  and  Management, 
Part  1:  Specification  of  ACSE,  Presentation  and  Session  Protocols  for  die  Use  by 
FTAM 

DAM  1,  Additional  Specifications  for  COBOL  Document  Types 

•  ISQ/IEC  ISP  10607-2,  ISPs  AFT  nn  -  File  Transfer,  Access,  and  Management, 
Part  2:  Definition  of  Document  Types,  Constraint  Sets  and  Syntaxes 

DAM  1,  Additional  Definitions 

-  DAM  2,  Additional  Specifications  for  COBOL  Document  Types 

DAM  3,  FTAM  Constraint  Set  and  Document  Type  for  CGM 

•  ISO/IEC  ISP  10607-3,  ISPs  AFT  nn  -  File  Transfer,  Access,  and  Management, 
Part  3:  AFT  11  -  Simple  File  Transfer  Service  ( Unstructured ) 

•  ISO/IEC  ISP  10607-4,  ISPs  AFT  nn  -  File  Transfer,  Access,  and  Management, 
Part  4:  AFT  12  -  Positional  File  Transfer  Service 

DAM  l.  Additional  Specifications  for  COBOL  Document  Types 

•  ISO/IEC  ISP  10607-5,  ISPs  AFT  nn  -  File  Transfer,  Access,  and  Management, 
Part  5:  AFT  22  -  Positional  File  Access  Service 

DAM  1,  Additional  Specifications  for  COBOL  Document  Types 

•  ISO/IEC  ISP  10607-6,  ISPs  AFT  nn  -  File  Transfer,  Access,  and  Management, 
Part  6:  AFT  12  -  File  Management  Service 

•  DISP  11190,  ISP  FDI3  -  FTAM  Use  of  Directory,  1993. 

9.11.7  Directory 

ITU-TS  is  developing  a  database  application  standard  for  logically  storing  directory 
information.  The  Directory  is  a  distributed  database  cm  users,  processes,  and  other  objects,  used 
to  provide  access  to  information  that  people  or  processes  require  prior  to  communicating.  The 
standards  are  in  the  following  X.500  Series  recommendations:  X.500,  X.501,  X.509,  X.511, 
X.518,  X.519,  X.520,  and  X.521.  A  report  by  Ovum,  X.500  and  die  Electronic  Directory:  the 
Business  Opportunity,  predicts  that  the  Directory  market  will  grow  to  $574  million  in  the  year 
2000.  [Ref.  OSN  1992b] 
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9.11.7.1  Directory  Services  and  Models53 

Directory  Services.  The  Directory  services  provide  a  specialized  hierarchical  database 
for  OSI  applications.  The  Directory  contains  information  about  objects  and  provides  structured 
mechanisms  few  accessing  that  information.  These  services  are  intended  to  provide  user  friendly 
naming  to  permit  a  user  to  specify  an  object's  name  and  then  retrieve  additional  addressing 
information.  The  two  key  aspects  of  the  OSI  Directory,  which  distinguish  it  from  other  database 
and  name-server  work,  are  [Ref.  OSN  1990d]: 

•  The  Directory  can  be  read,  modified,  and  searched  remotely  via  OSI  protocols. 

•  A  highly  distributed  database  is  provided  by  Directory  System  Agents  (DSAs). 

Directory  Models.  The  following  four  models  define  the  Directory  services  [Ref.  OSN 

1990d]: 

•  The  informational  model  describes  the  Directory  Information  Base  (DIB).  The  DIB 
contains  all  the  information  to  which  the  Directory  provides  access.  This  model  is 
concerned  only  with  die  logical  structuring  of  the  information. 

•  The  functional  model  describes  interactions  that  take  place  between  the  various  DSAs 
that  comprise  die  Dictionary. 

•  The  organizational  model  describes  how  portions  of  the  Directory  tree  map  onto  the 
DSAs.  This  includes  issues  of  replication  and  access  control. 

•  The  security  model  of  Directory  services  describes  the  service  in  terms  of 
authentication  and  authorization. 

The  DIB  model  is  a  conceptual  information  model  storing  information  about  OSI  objects.  It  is 
structured  hierarchically  using  a  tree  structure  known  as  die  Directory  Information  Tree  (DIT).  The 
Directory  standard  provides  Directory  schema  that  can  be  used  by  a  profile  group  to  define  its  DIT. 

Directory  Entries.  TV  TIB  comprises  object  entries  and  alias  entries.  An  object  entry 
is  die  primary  collection  of  information  in  die  DIB  about  an  object  in  the  real  world.  An  alias  entry 
points  to  another  object  entry  and  is  primarily  used  to  provide  a  user-friendly  name  to  the 
referenced  object  entry.  An  object  in  the  real  world  can  be  represented  by  more  than  one  alias 
although  it  can  be  represented  by  at  most  one  object  entry  in  the  DIB. 

Directory  Attributes.  An  entry  is  described  by  a  set  of  attributes.  Table  26  shows 
some  of  the  attribute  types  defined  by  the  Directory  standard.  Attribute  types  can  also  be  defined 
by  profile  groups.  Among  die  attributes  of  an  entry,  there  are  die  distinguished  attributes  that  are 
used  to  name  die  entry.  The  type  used  in  a  distinguished  attribute  is  called  a  distinguished  attribute 
type,  while  some  of  die  attribute  values  (normally  at  most  one)  of  a  distinguished  attribute  type  are 
called  distinguished  values. 

Directory  Classes.  Entries  of  similar  characteristics  are  grouped  into  object  classes. 
Examples  of  object  classes  are  Country,  Organization,  Person,  Alias,  Application  Entity,  DSA, 
and  Device.  A  specification  of  an  object  class  describes  (mandatory)  attributes  that  must  belong  to 
the  Person  object  class  by  requiring  the  Common  Name  and  Surname  attributes  to  be  mandatory, 
and  die  Telephone  Number  and  User  Password  attributes  to  be  optional 

Directory  Structure.  The  structure  of  the  DIB  is  described  by  the  Directory  schema. 
The  Directory  schema  consists  of  a  set  of  structural  rules  on  die  DIT.  It  provides  templates  for  the 
definition  of  object  classes,  attribute  types,  and  abstract  syntaxes.  Object  classes,  attribute  types. 


53  Portions  of  this  lection  have  been  excerpted  Cram  [Ting  1991]. 
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and  attribute  syntaxes  ue  defined  by  a  profile  group  or  a  Directory  administrator.  The  Directory 
schema,  in  providing  templates  for  these  definitions,  can  improve  consistency  in  die  definitions. 
For  instance,  it  prevents  die  creation  of  an  inappropriate  containment  relation  in  the  DIT,  the  use  of 
an  inappropriate  attribute  type  in  an  object  class  definition,  and  the  addition  of  an  inappropriate 
value  of  a  syntax  not  matching  the  syntax  defined  for  the  attribute  type.  ~  ^ 


Table  26.  Directory  Attribute  Types 


|  X.600  Attribute  Type*  j 

System 

nkUnt  /Meee 

VXjSCt  UMI 

AKased  Object  Name 
Knowledge  Information 

Labeling 

Common  Nama 

Surname 

Serial  Number 

Geographical 

Country  Name 

Locality 

State  or  Province 

Street  Address 

Organizational 

Organization 

Organization  Unit 

Tide 

Postal 

Postal  Address 

Postal  Coda 

Post  Office  Box 

Physical  DeHverv  Office 

Explanatory 

Description 

Search  Guide 

Business  Category 

Telecommunications 

Telephone  Number 

Telex  Number 

Telex  Terminal  ID 

Fax  Telephone  Number 
International  ISDN  Number 
Registered  Address 
Destination  Indicator 

Preferences 

Preferred  Delivery  Metf 

OSI  Application 

Presentation  Address 

Sudd.  Aooiication  Context 

Security 

User  Password 

User  Certificate 

CA  Certificate 

Authority  Revocation  List 
Certificate  Revocation  List 
Cross  Certificate  Pair 

Relational 

Mambar 

Owner 

Role  Occupant 

Source:  [Tang  1992]. 


Directory  Distributed  Services.  In  a  large  network  environment,  the  Directory 
services  may  be  distributed  among  multiple  DSAs.  Despite  the  distributed  nature,  the  basic 
philosophy  of  the  Directory  services  is  transparent  distribution  (i.e.,  a  DUA  views  the  Directory  as 
a  single  object).  This  means  that  the  object  entry  information  retrieved  by  a  DUA  from  a  particular 
DSA  should  be  the  same,  had  the  object  entry  information  been  retrieved  from  a  different  DSA.  To 
preserve  the  DUA’s  view  of  a  single  Directory  object,  mechanisms  must  be  defined  to  allow 
partitioning  of  the  DIB. 

One  of  the  design  goals  of  the  Directory  services  is  that  requests  addressed  to  any  DSA 
must  produce  results  that  are  the  same  regardless  of  the  DSA  contacted.  To  satisfy  this  goal,  a 
DSA  must  have  some  knowledge  of  the  place  where  the  requested  information  is  located  in  the 
DIT.  In  the  extreme  case,  the  entire  DIB  is  contained  within  a  single  DSA,  in  which  case  the  goal 
is  trivially  satisfied.  In  fact,  a  centralized  DSA  was  very  common  during  the  early  DSA 
implementations,  hi  general,  information  in  die  DIB  is  distributed  among  the  DSAs.  Each  DSA 
maintains  one  or  more  substructures  of  the  DIT.  Consequently,  the  DSAs  may  need  to 
communicate  with  each  other  to  resolve  requests  from  a  DUA. 

Directory  Protocols.  When  a  DUA  conveys  a  request  to  a  DSA  and  a  DSA  responds, 
the  Directory  Access  Protocol  (DAP)  is  used.  If  the  DSA  contacted  by  the  DUA  cannot  process  the 
request,  it  may  propagate  or  “chain”  the  request  to  another  DSA  that  may  repeat  the  chaining 
operation,  or  the  initial  DSA  may  provide  the  DUA  with  a  “referral”  to  another  DSA  more  likely  to 
contain  the  information.  The  protocol  used  among  DSAs  to  convey  a  service  request  is  known  as 
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the  Directory  System  Protocol  (DSP).  When  DSAs  replicate  information  to  enhance  availability 
and  performance,  two  other  protocols  are  used.  The  Directory  Operational  Binding  Management 
Protocol  (DOP)  is  used  to  initialize  or  terminate  a  relationship  between  two  DSAs  regarding  the 
supply  and  consumption  of  replicated  information  and  knowledge  regarding  the  content  of  DSAs. 
The  Directory  Information  Shadowing  Protocol  (DISP)  is  used  to  initially  provide  and  refresh 
replicated  information.  [IGOSS  1993]. 

9.11.7.2  Directory  Standards 

SC21/WG4  and  ITU-TS  are  working  on  OSI  directories.  Second  editions  to  Parts  1-8  of 
The  Directory  (ISO  9594)  are  expected  by  the  end  of  1994  (the  ITU-TS  ballot  closed 
November  1993).  The  status  of  standards  for  the  Directory  are  as  follows: 

•  ISO/IEC  9594- 1 ,  The  Directory ,  Part  1 :  Overview  of  Concepts,  Models  and  Services, 
December  1990  (X.500) 

AM  1,  Replication,  Schema  and  Access  Control 

WD  9594-1/9  WDAMs,  Amendments  to  Parts  1  to  9  on  Internationalization  of  the 
Directory  Enhancement  of  Directory,  June  1993  [SC21  N  7931]  (PDAMs 
expected  July  1994) 

WD  9594-1/9  WDAMs,  Amendments  to  Parts  1  to  9  on  Enhancement  of 
Directory  Operational  Security,  June  1993  [SC21  N  7932]  (PDAMs  expected 
November  1994) 

WD  9594-1/9  WDAMs,  Amendments  to  Parts  1  to  9  on  Directory  Schema 
Migration,  June  1993  (new  work  item  proposal)  [SC21  N  7942]  (PDAMs 
expected  November  1994) 

DIS  9594-1.2,  The  Directory,  Part  1:  Overview  of  Concepts,  Models  and 
Services,  Edition  2  (incorporates  AM  1),  1993  (X.500: 1993) 

•  ISO/IEC  9594-2,  The  Directory,  Part  2:  Models,  December  1990  (X.501) 

AM  1,  Access  Control 
AM  2,  Schema  Extensions 
AM  3,  Replication 

DIS  9594-2.2,  The  Directory,  Part  2:  Models,  Edition  2  (incorporates  AM  1,  AM 
2,  and  AM  3),  1993  (X.501)  (X.501.1993) 

•  ISO/IEC  9594-3,  The  Directory,  Part  3:  Abstract  Service  Definition,  December  1990 
(X.511) 

AM  1,  Access  Control 

AM  2,  Replication,  Schema  and  Enhanced  Search 

ISO  9594-3.2,  The  Directory,  Part  3:  Abstract  Service  Definition,  Edition  2 
(incorporates  AM  1  and  AM  2),  1993  (X.511:1993) 

•  ISO/IEC  9594-4,  The  Directory,  Part  4:  Procedures  for  Distributed  Operations, 
December  1990  (X.518) 

AM  1,  Access  Control 

AM  2,  Replication,  Schema  and  Enhanced  Search 

ISO  9594-4.2,  The  Directory,  Part  4:  Procedures  for  Distributed  Operations, 
Edition  2  (incorporates  AM  1  and  AM  2),  1993  (X.518:1993) 

•  ISO/IEC  9594-5,  The  Directory,  Part  5:  Protocol  Specifications,  December  1990 
(X.519) 

AM  \,  Replication 

ISO  9594-5.2,  The  Directory,  Part  5:  Protocol  Specifications,  Edition  2 
(incorporates  AM  1),  1993  (X.519:1993) 
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•  ISO/IEC  9594-6,  The  Directory,  Put  6:  Selected  Attribute  Types,  December  1990 
(X.520) 

AM  1,  Schema  Extensions 

ISO  9594-6.2,  the  Directory,  Part  6:  Selected  Attribute  Types,  Edition  2 
(incorporates  AM  1),  1993  (X.520: 1993) 

•  ISO/IEC  9594-7,  The  Directory,  Part  7:  Selected  Object  Classes,  December  1990 
(X.521) 

AM  1,  Schema  Extensions 

ISO  9594-7.2,  The  Directory,  Part  7:  Selected  Object  Classes,  Edition  2 
(incorporates  AM  1),  1993  (X.521: 1993) 

•  ISO/IEC  9594-8,  The  Directory,  Part  8:  Authentication  Framework,  December  1990 
(X.509.1988) 

AM  1,  Access  Control 

WDAM,  Extensions  for  Certificate  Identifications,  1993  (new  work  item  accepted 
April  1993;  PDAM  expected  July  1995) 

DIS  9594-8.2,  The  Directory,  Part  8:  Authentication  Framework,  Edition  2 
(incorporates  AM  1),  1993  (X.509:1993) 

•  ISO  9594-9,  The  Directory,  Part  9:  Replication,  November  1993  (X.525:1993). 

The  following  standards  are  under  development  by  ISO. 

•  WD  9594-10,  PICS  Proforma,  for  the  OSI  Directory  DU  A  Protocol,  December  J990 
(fast  track  ballot  of  ITU-TS  standard  has  been  requested)  (X.58 1:1992) 

•  WD  9594-11,  PICS  Proforma,  for  the  OSI  Directory  DSA  Protocol,  December  1990 
(fast  track  ballot  of  ITU-TS  standard  has  been  requested)  (X. 582: 1992) 

•  WD  9594-w,  Use  of  Systems  Management  for  Administration  of  die  Directory, 
June  1993  [SC21  N  7930]  (CD  expected  in  July  1994,  DIS  in  July  1995,  and  IS  in 
July  1996). 

The  scope  of  WD  9594-w  is  to  define  a  set  of  Managed  Objects  to  support  Directory 
operational  information  (Le.,  that  information  the  Directory  uses  to  guide  its  own  operations). 
Requirements  for  management  of  Directory  systems  (e.g.,  performance,  accounting)  need  to  be 
determined  as  well  as  consideration  and  identification  of  the  most  appropriate  mechanisms  and 
protocols  to  be  used  to  provide  the  various  administration  services  for  the  Directory.  This 
operational  information  would  be  accessible  through  the  CMIS  and  CMIP;  however,  die  Directory 
Information  Base  will  continue  to  be  only  accessible  through  die  Directory  Services  and  Protocols. 

The  ITU-TS  Directory  Defect  Resolution  Committee  has  produced  a  Directory 
Implementor's  Guide,  January  1993  [SC21  N  7566],  which  is  a  compilation  of  reported  defects  in 
the  1988  ITU-TS  X.500  Recommendations  (ISO/IEC  9594)  standards  and  their  resolutions.  It  is  a 
ITU-TS  record  of  defects,  not  a  formal  ISO  record  of  Directory  defects,  intended  to  be  an 
authoritative  source  of  information  for  implementors  to  read  in  conjunction  with  the 
Recommendations/Standards  themselves.  [Ref.  SC21  N  6012  1991]  The  Guide  provides 
guidance  to  implementors  on  how  they  may  submit  defects  as  well  as  insights  into  the  procedures 
by  which  their  reported  defects  will  be  processed. 

In  a  liaison  statement  to  SC6  concerning  a  request  for  incorporation  of  new  protocol 
information  attributes  in  9594-6/AM  1,  SC21  states  that  it  would  be  an  error  to  introduce 
networking  information  into  the  OSI  (Application)  Directory.  Instead,  SC21  believes  these 
requirements  should  be  satisfied  in  Network  directory  facilities.  [Ref.  SC21  N  6974  1992] 
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9.11.7.3  Enhancements  to  Directory  Standards 

Although  the  Directory  has  introduced  a  type  for  strings  encoded  in  the  Universal  Coded 
Character  Set  (UCS)  (ISO  10646),  the  UK  has  argued  that  it  is  insufficient  for  the  Directory  to 
support  an  international,  distributed  environment  Instead,  a  fully  international  Directory  must 
address  (1)  local  users  using  a  local  writing  system  and  character  set  and  (2)  external  users  who 
use  different  writing  systems  and  character  sets.  The  UK,  therefore  proposed  that  work  should  be 
started  to  cover  the  following  [Ref.  SC21  N  6821  1992]: 

•  Locale-dependent  operations  involving  string  handling 

•  Alternative  names  as  Relative  Distinguished  Names  (RDN) 

•  Locale-dependent  alternate  attribute  values. 

In  June  1992,  SC21  accepted  a  proposal  for  a  NWI  entitled  Internationalization  of  the 
Directory  [SC21  N  7019  1992],  which  it  assigned  to  WG4  for  development  [Ref.  SC21  N  7579 
1993]  The  NP  will  result  in  an  addendum  or  addenda  to  ISO  9594-1  and  ISO  9594-9.  It  is  in  WD 
status  [SC21  N  7931,  June  1993]  and  the  target  dates  are  PDAM  in  May  1994,  DAM  in  May 
1995,  and  AM  in  May  19%. 

JTC1  has  accepted  a  NWI  for  Certificate  Definitions  [SC21  N  7102],  The  NWI  would  be 
an  amendment  to  ISO  9594-8  and  would  extend  the  definitions  of  the  Certificate  Revocation  List 
User  Certificate,  and  Revocation  Certificate.  This  work  should  not  be  confused  with  another  NP 
[SC21  N  7020]  (see  Section  1 1.2.2.7)  that  will  address  the  use  of  9594-8  Certificates  to  provide 
authentication  and  some  other  related  security  services. 

The  Directory  group,  at  its  May  1992  meeting  decided  that  the  Directory  standard  would 
have  to  be  extended  to  use  the  Upper  Layer  Security  services.  Thus,  they  are  submitting  a 
proposal  for  an  NP  [SC21  N  7020]  on  enhancement  of  directory  operational  security  (see  also 
Section  11.2.2.7).  [Ref.  SC21  WG4  N  1527  1992] 

9.11.7.4  Example  Interoperability  Parameters  for  Directory 

Two  international  groups  are  working  on  functional  standards  (profiles)  for  the  Directory. 
The  issues  being  addressed  by  the  OIW  Directory  Services  SIG  and  the  EWOS/ETSI  Directory 
Expert  Group  indicate  options  within  the  Directory  standard  and  areas  where  baseline  standards 
may  be  exceeded  to  address  practical  implementation  problems.  Examples  of  the  issues  and 
options  are  [Ref.  IST/21: 1868  1989]: 

•  Classification  of  minimum  schema  capabilities. 

•  Classification  of  baseline  structure  rules — mandates  the  capability  to  access  a  standard 
Directory  tree  (which  may  be  extended  to  a  wide  variety  of  entries). 

•  Definition  of  maximum  APDU  size — eases  design  of  high-performance  DSAs  (e.g.,  to 
ensure  the  Directory  can  respond  in  seconds)  and  eases  network  problems  in  providing 
quality  of  service. 

•  Pragmatic  constraints  on  filters — protects  the  Directory  from  pathological  conditions 
and  potentially  simplifies  design. 

•  Holes  in  distributed  operation  definitions — there  are  many  undefined  aspects  for 
distributed  operations  (e.g.,  how  to  handle  errors). 

•  Constraints  on  alphabets — Directory  uses  T.61  strings.  Directory  profiles  are 
addressing  rejection  of  strings  that  contain  non-T.61  characters  and  restrictions  on 
permissible  characters  (e.g.,  escape  characters). 

•  Constraints  on  integer  values — defines  a  minimum  size  integer  that  must  be  supported. 
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•  ftf  anthwitifatiftn— «n«nriim»  n»»  nf  simple  uncorroborated  inthffflticatinn 
that  supports  external  authentication  within  a  closed  domain. 

•  Augmentation  of  attribute  syntax  rules — augments  the  standards  material  with  practical 
rules. 

•  ASN.l  rules — mandates  support  of  ASN.l  identifier  tags  that  arc  three  octets  in  length 
(and  no  longer)  and  requires  constructed  string  elements  not  to  be  nested  more  than 
one  deep. 

•  Strong  authentication  algorithms — proposing  alternatives  to  the  use  of  RSA™  (a 
licensed  product)  for  digital  signatures. 

A  number  of  options  can  be  defined  for  services  provided  by  DUAs.  Classes  of  these 
options  include  supported  abstract  operations;  supported  types  and  levels  of  authentication;  and 
ability  to  use  a  Continuation  Reference  to  progress  an  operation.  Options  for  abstract  operations 
include  read,  compare,  list,  search,  add  entry,  remove  entry,  modify  entry,  modify  Directory 
Name,  and  abandon;  these  may  be  bundled  in  many  ways  in  various  profiles.  Two  types  of 
authentication  are  defined  in  Directory  (i.e.,  user  authentication  and  peer-entity  authentication)  and 
three  levels  of  security  at  which  authentication  may  be  performed: 

•  Identify-only  authentication,  providing  no  confidence  that  the  identity  presented  to  the 
Directory  is  authentic 

•  Simple  authentication,  based  on  passwords,  which  may  (depending  on  how  the 
passwords  are  administered  and  protected)  provide  more  confidence  than  identify-only 
authentication 

•  Strong  authentication,  based  on  the  use  of  digital  signatures  that  rely  on  the  use  of 
public  key  cryptographic  techniques. 

finally,  there  are  direction  options  for  strong  authentication.  Peer-entity  strong  authentication  may 
be  one  way  (in  which  one  peer  authenticates  the  identity  of  the  other  peer;  two  way  (in  which  both 
peas  authenticate  each  other);  or  three  way.  [Ref.  IGOSS 1993] 

Another  set  of  Directory  interoperability  parameters  is  defined  by  the  options  for  DUAs. 
The  two  groups  of  DSA  options  are  DSA  category  (solitary  and  cooperative)  and  the  supported 
types  and  levels  of  authentication.  A  “solitary”  DSA  is  a  DSA  designed  to  support  a  centralized 
DIT  only  and  is  unable  to  communicate  with  any  other  DSA,  whereas  a  cooperative  DSA  is  used  to 
specify  a  bundle  of  functionality  that  allows  a  DSA  to  be  part  of  a  community  of  DSA  that 
communicates  in  various  ways  to  support  a  distributed  DIT.  A  solitary  DSA  does  not  support 
DSP,  DISP,  DOP,  referrals,  and  knowledge  references.  A  cooperative  DSA  is  able  to  cooperate, 
either  directly  or  indirectly,  with  other  DSAs  to  provide  Directory  services  that  are,  to  a  large 
extent,  independent  of  how  the  DIT  is  distributed.  In  direct  cooperation,  the  DSP  may  be  both  a 
responder  and  an  initiator,  supporting  the  chained  mode  of  operation.  Indirect  cooperation  occurs 
when  a  DSA  supports  DAP  only  or  when  the  responder  role  for  DSP  is  supported.  Authentication 
options  for  DSAs  are  similar  to  those  for  DUAs  described  above.  [Ref.  IGOSS  1993] 

9.11.7.5  Standardized  Profiles  for  Directory 

The  Directory  ISPs  under  development  by  EWOS  include: 

•  DISP  10615-1,  ISPs  ADI  nn  ~  OSI  Directory,  Part  1:  ADI  11,  DUA  Support  of 
Directory  Access,  January  1993 

•  DISP  10615-2,  ISPs  ADI  nn  —  OSI  Directory,  Part  2:  ADI  12,  DSA  Support  of 
Directory  Access,  January  1993 

•  DISP  10615-3,  ISPs  ADI  nn  ~  OSI  Directory,  Part  3:  ADI  21,  DSA  Responder 
Role,  July  1993 

Chapter 9  209  Network  Service  Standards 

UNCLASSIFIED 


UNCLASSIFIED 


•  DISP  10615*4,  ISPs  ADI  rut  -  OSI  Directory,  Part  4:  ADI  22,  DSA  Initiator  Role, 
July  1993 

•  pDISP  10615-5,  ISPs  ADI  rut  —  OSI  Directory,  Part  5:  ADI  31,  DUA  Support  of 
Distributed  Operations,  1993 

•  pDISP  10615-6,  ISPs  ADI  rut  —  OSI  Directory,  Part  6:  ADI  32,  DSA  Support  of 
Distributed  Operations,  1993 

•  pDISP  10615-7,  ISPs  ADI  rut  --  OSI  Directory,  Part  7:  ADI  41,  Strong 
Authentication,  1993 

•  pDISP  10616,  ISP  FDI 11  -  Directory  Data  Definitions  -  Common  Directory  Use, 
September  1993 

•  DISP  1 1 189,  ISP  FDI2  -  MHS  Use  of  Directory,  1993 

•  DISP  11190,  ISP  FDI3  -  FTAM  Use  of  Directory,  1993. 

Future  profiles  for  Directory  are  expected  to  follow  the  taxonomy  of  Table  27. 


Table  27.  Taxonomy  for  Directory  Profilee 

Abl  1  Directory  Access  Profitos  (DAP*) 

AD1 11  DUA  Support  for  Directory  Access 
AD1 12  DSA  Support  for  Directory  Accms 
ADI  2  Directory  System  Profite*  (DSP*) 

ADI  21  FI— poncfor  Roto 
ADI  22  locator  Role 
ADI  3  Distributed  Operations  Profite* 

ADI  31  DUA  Support  of  Distributed  Operations 
ADI  32  DSA  Support  of  Distributed  Operations 
ADI  4  Security  Profifo*  (a.g..  strong  ues  at  authentication) 

ADI  5  Shadowing  and  Replication  Profltos 
ADI  6  Directory  Administration  ProMse 

ADI  61  AdriiMatralfoaAieaOalMfonaiidGrafuilari^ 

ADI  62  CoNsctivc  Attributes 
ADI  63  Schama  Administration 
ADI  64  Operational  Behavior 
ADI  66  Knowledge  Administration 

FD1 1  Directory  Data  Definition  (Schema  Profilee) 

FD1 11  Common  Directory  Use 
FD1 12  Collective  Attributes 
FD1 13  Schema  Management 
FD1 14  DSA  Modal  Information 
FD1 15  Operational  Attributes 
FDI  2  MHS  Use  of  Directory 
FDI  3  FTAM  Use  of  Directory 

FDI  4  EDI  Use  of  Directory 
FDI  6  TP  Use  of  Directory 

Sources:  WDTR  10000-2.4 ,  August  1083  and  [EWOS/TA03/424  1993],  October  1993. 


9.11.8  Job  Transfer  and  Manipulation  (JTM) 

JTM  (ISO/IEC  8831  and  8832)  was  originally  designed  for  remote  off-line  (batch) 
processing.  It  uses  a  processing  model  based  on  movement  of  entities  called  "documents”  and  the 
exchange  of  these  entities  with  users.  Exchanges  are  specified  in  work  specifications  that  include  a 
data  structure  and  an  envelope  carrying  the  document  hi  Basic  Class  JTM  a  single  document  can 
be  sent  to  a  processing  element  In  Full  JTM  (ISO  8832/AMI,  Full  Class  Protocol)  multiple 
documents  and  multiple  processing  steps  are  permitted.  Capabilities  of  JTM  are  being  included  in 
standards  for  FTAM  (e.g.,  RA)  and  the  ASEs  (e.g.,  RPC).  [Ref.  SC21  N  4356  1990] 
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The  United  States  stated  in  ISO  in  Match  1990  that  there  are  no  US  user  requirements  nor 
any  organization  in  the  United  States  willing  to  provide  resources  for  JTM  standards.  [Rtf.  SC21 
N  4641  1990]  AFNOR  has  similarly  found  little  interest  in  industry  for  JTM  and  recommended 
further  work  be  suspended.  [Ref.  SC21  N  4603  1990]  Nevertheless,  the  reassessment  report  for 
JTM  Full  Class  [SC21  N  4679  Revised]  recommended  completion  of  the  International  Standard 
texts,  given  the  advanced  state  of  the  work.  The  recommendation  was  approved  by  SC21  in  June 
1990  [Ref.  IST/21:  2160  1990]. 

The  current  versions  of  JTM  are  as  follows: 

•  ISO/IEC  8831:1992,  Job  Transfer  and  Manipulation  Concepts  and  Services, 
Edition  2,  March  1992 

•  ISO/IEC  8832:1992,  Specification  of  the  Basic  Class  and  Full  Protocol  for  Job 
Transfer  and  Manipulation,  Edition  2,  March  1992. 

9.11.9  Distributed  Transaction  Processing 

9.11.9.1  Description  of  TP 

OSI  Distributed  Transaction  Processing  (TP)  supports  a  set  of  logically  related  operations 
affecting  interrelated  data  and  other  resources  across  separate  open  systems  in  which  the 
transaction  is  not  simply  an  exchange  of  messages  but  in  which  the  exchanges  form  a  protected  and 
indivisible  set  of  messages.  OSI  TP  operations  are  characterized  by  the  four  ACID  properties 
supported  by  CCR  (see  Section  9.1 1.3.2):  atomicity,  consistency,  isolation,  and  durability.  [Rtf. 
IGOSS  1993] 

The  TP  protocol  makes  use  of  the  facilities  of  the  Commitment,  Concurrency,  and 
Recovery  (CCR)  application  service  element  (ASE)  and  the  Association  Control  Service  Element 
(ACSE)  (see  Section  9.11.3).  It  acts  as  a  mediator  for  these  protocols  and  operates  in  an 
environment  of  many  communicating  pairs  over  many  application  associations.  On  the  other  hand, 
CCR  and  ACSE  operate  in  a  single  peer-to-peer  environment  As  a  mediator,  TP  does  not  specify 
any  style  of  data  transfer.  It  does  provide  an  environment  for  an  ASE  to  transfer  data.  It  is  up  to  a 
TP  application  to  determine  its  user-ASE(s)  to  transfer  data.  Although  there  are  user-ASEs  such  as 
Remote  Procedure  Call  (RPC;  see  Section  9.11.3.5)  and  RDA  (see  Section  6.2.3)  that  can  operate 
with  TP,  one  can  define  a  user- ASE  that  is  specific  for  a  TP  application. 

The  user  requirements  addressed  by  ISO  10026  are  to: 

•  Define  procedures  that  support  distributed  transactions  in  order  to: 

Allow  a  distributed  transaction  to  be  organized  into  a  transaction  tree 

Provide  multi-party  coordination,  including  local  resources 

Allow  restoration  to  a  consistent  state,  following  failure  of  the  state/context  of  a 

distributed  transaction  and  of  distributed  information 

Allow  tire  detection  of  failure  to  achieve  consistency 

Allow  a  distributed  transaction  to  be  restarted  following  successful  state 
restoration 

Indicate  successful  completion  or  failure  of  a  transaction 

•  Provide  for  the  delimitation  of  a  sequence  of  logically  related  transactions 

•  Allow  the  grouping  of  transactions  within  an  applications  process 

•  Allow  for  access  control,  access  control  granularity  on  groups  of  TP  object, 
authentication,  and  non-repudiation 
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•  Allow  conformance  testing  of  the  protocol  and  delineate  clearly  the  static  and  dynamic 
conformance  requirements  (through  a  PICS  statement). 

9.11.9.2  TP  Concepts  end  Options 

A  number  of  concepts  are  contained  in  TP  in  the  areas  of  transaction  categories,  control 
modes,  transaction  types,  and  roles.  These  concepts  illustrate  some  of  the  TP  options  and  may  be 
described  as  follows  [Ref.  IGOSS  1993]: 

•  Categories  of  transaction 

Application-supported  transactions — Allows  two  systems  to  communicate  using  a 
TP  Dialogue.  The  ACID  properties  are  the  responsibility  of  the  end  user. 
Provided-supported  transactions — Allows  two  systems  to  communicate  using  all 
die  TP  functions.  The  ACID  properties  are  the  responsibility  of  the  TP  service 
provider. 

•  Control  modes 

Shared  control — A  mode  that  does  not  explicitly  control  the  exchange  of 
messages.  Message  exchange  is  based  solely  on  the  internal  semantics  of  the 
programs,  and  they  may  use  the  TP  Dialogue  at  their  discretion.  The  TP  service 
provider  does  not  care  about,  nor  is  it  aware  of,  any  message  collisions. 

Polarized  control — A  mode  that  controls  the  exchange  of  messages  between  the 
two  systems  via  a  token.  Under  normal  conditions,  a  system  can  use  the  TP 
Dialogue  only  if  it  has  the  token — TP  will  enforce  this  requirement  Under 
extraordinary  circumstances,  such  as  an  abort  either  system  can  use  the 
Dialogue. 

•  Transaction  types 

Chained  transaction — A  series  of  related  transactions,  such  as  a  batch  of  accounts 
receivable  transactions,  which  start  and  continue  until  die  batch  ends.  The 
sequence  of  events  is  that  die  first  transaction  builds  the  transaction  tree,  uses  it 
and  either  commits  or  rolls  back;  die  second  transaction  uses  the  transaction  tree 
and  either  commits  or  rolls  back;  and  the  third-to-the-last  transactions  each 
follows  the  same  pattern.  After  the  last  transaction,  the  transaction  tree  is 

didanHwl 

Unchained  transaction — A  transaction  that  establishes  a  transaction  tree  and 
communications  with  another  program.  Sometime  during  the  communications,  it 
is  determined  that  a  transaction  should  occur.  That  portion  of  the  communication 
would  be  placed  under  the  ACID  properties  and  be  recoverable  by  OSI  TP.  The 
transaction  starts  and  completes  with  either  a  commit  or  roll  back.  The  transaction 
tree  may  or  may  not  be  disbanded;  if  it  remains,  it  is  ready  for  the  next 
transaction. 

None  (application  supported) — In  the  case  of  the  application-supported  category 
of  transactions,  there  is  an  undefined  relationship  between  two  systems — how  a 
transaction  starts  and  ends  is  an  end-user  concern. 

•  Roles  for  transactions 

General  transaction  role — The  system  performs  the  task  of  the  root  node.  It  starts 
a  transaction,  and  all  participants  in  the  transaction  are  its  machines. 

Responder  transaction  role — A  system  may  only  be  a  leaf  on  a  transaction  tree.  It 
responds  to  a  request  to  join  a  transaction  and  may  not  delegate  any  tasks  to 
another  system — it  can  only  respond.  A  large  database  server  might  be  an 
example. 

General  transaction  role — A  system  may  be  a  root,  intermediate,  or  leaf  node 
depending  tm  how  it  is  used  at  a  specific  time.  This  is  the  most  robust  and 
general-purpose  product  that  could  be  procured  and  that  can  serve  any  role. 
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9.11.9.3  TP  Standards 

ISO/IEC  10026,  OSI  Distributed  Transaction  Processing,  comprises  die  following  parts: 

•  ISO/IEC  10026-1,  Part  1:  Model,  December  1992  [SC21  N  7457]  (X. 860:1992) 

PD  AM  1,  Amendment  1:  Commitment  Optimization,  September  1993  [SC21  N 
8219, 8220, 7649)  (DAM  expected  June  1994;  and  AM  expected  June  199 5) 

•  ISO/IEC  10026-2,  Part  2:  Service,  August  1992  [SC21  N  7304]  (X.861:1992) 

PD  AM  1,  Amendment  1:  Commitment  Optimizations,  September  1993  [SC21 
N  8220] 

•  ISCVIEC  10026-3,  Part  3:  Transaction  Processing  Protocol  Specification,  December 
1992  [SC21  N  7518]  (X.862) 

PD  AM  1,  Amendment  1:  Commitment  Optimizations,  September  1993  [SC21 
N  7649] 

•  ISO/IEC  10026-4,  Part  4:  PICS  Proforma,  SC21/WG5,  October  1993 
[SC21  N  8290]  (X.863) 

•  ISO/IEC  10026-5,  Part  5:  Application  Context  Proforma,  1993 

•  ISO/IEC  10026-6,  Part  6:  Unstructured  Data  Transfer,  1993 

•  CD  10026-7,  Part  7:  Message  Queueing,  July  1993  [SC21  N  8148]  (DIS  text 
expected  early  in  1994). 

In  addition  to  the  CD-level  amendments  (PDAMs)  on  commitment  optimizations  cited 
above,  the  following  working  draft  amendments  (WDAMs)  apply  to  Parts  1-3: 

•  Distributed  Transaction  Processing  Dialogue  Recovery  and  User  Suspension  of  a 
Dialogue  [SC21  N  6710]  (PDAMs  expected  November  1995,  DAMs 
November  1996,  and  AMs  November  1997) 

•  Transaction  Processing  Association  Pool  Management,  February  1992  [SC21 N  7604] 
(formerly  entitled  Association  Management)  (PDAMs  expected  July  1994,  DAM 
July  1995,  and  AM  July  1996) 

•  Transaction  Processing  Sub-Transactions,  SC21/WG5,  July  1991  [SC21  N  6236] 
(PDAMs  expected  November  1995,  DAMs  November  1996,  and  AMs 
November  1997) 

•  Transaction  Processing  Separate  Data  and  Commit  Associations,  July  1991 
[SC21  N  6240]  (PDAMs  expected  November  1995,  DAMs  November  1996,  and 
AMs  November  1997) 

•  Transaction  Processing  Security,  July  1991  [SC21  N  6232]  (PDAMs  expected 
November  1995;  DAMs  November  1996;  and  AMs  November  1997). 

CD  1 1587.2  is  the  second  draft  of  a  standard  for  Application  Content  for  Systems 
Management  with  Transaction  Processing,  July  1993  [SC21  N  7899]  (editing  meeting  February 
1994;  initiation  of  ITU-TS  approval  ballot  expected  June  1995)  (X.702). 

Significant  changes  to  the  TP  model  (ISO  10026-1)  made  in  December  1990  were  removal 
of  dynamic  switching  between  chained  and  unchained  transactions,  thus  enabling  conforming 
systems  to  implement  any  one  of  three  modes  of  operation:  application-supported  transaction, 
provider-supported  chained  transaction,  and  provider-supported  unchained  transaction.  Provided- 
supported  chained  transactions  require  that  each  transaction  within  a  dialogue  use  full  two-phase 
commit  procedures  (CCR),  while  provided-supported  unchained  transactions  always  start  with 
application-supported  transactions  (no  CCR)  with  an  explicit  request  for  two- phase  commit 
support  for  each  transaction  that  requires  provider-supported  commitment 
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The  TP  protocol  document  (ISO  10026-3)  has  beat  restructured  into  a  form  intended  to  be 
more  easily  understood  with  ampler  descriptive  techniques.  In  addition,  there  were  changes  to 
simplify  and  correct  protocol  procedures.  Special  care  was  given  to  the  two-phase  commit 
protocol  and  its  use  of  CCR  services  to  ensure  that  all  collision  cases  were  resolved.  [Ref.  SC21  N 
5603  1990]  ISO  10026-3  does  not  provide  a  data  transfer  facility,  leaving  the  TP  user  free  to 
choose  a  data  transfer  paradigm  that  best  suits  the  user’s  needs. 

Unstructured  Data  Transfer  (UDT)  for  OSI  Transaction  Processing  (ISO  10026-6)  allows 
interconnection  of  computer  systems  from  different  manufacturers,  including  those  under  different 
management;  of  different  levels  of  complexity;  and  of  different  technologies.  UDT  is  not  suitable 
outside  die  TP  environment 

The  new  work  item  accepted  by  JTC1  for  Other  Data  Transfer  for  OSI  TP  has  been  redded 
Message  Queueing  (CD  10026-7).  Included  in  the  scope  of  this  work  is  development  of  TP 
queue  services  that  would  support  transactions  broken  down  into  multiple  steps.  These  services 
could  also  be  used  as  the  basis  for  a  deferred  transaction  initiation  mechanism  or  as  a  mechanism 
for  reliable  message  transfer.  [Ref.  SC21  N  5184  1990]  ISO  status  is  expected  in 
November  1994. 

ISO  10026  will  be  used  by  the  RDA  standard  and  is  being  considered  for  use  by  RPC, 
extensions  to  IRDS,  and  extensions  to  FT  AM.  It  is  the  first  Application  Layer  service  for 
distributed  processing.  [Ref.  SC21  N  4759  1990] 

TP  is  dependent  on  a  revised  version  of  CCR  dial  was  progressed  in  1989.  Two  formal 
descriptions  of  TP  have  been  produced,  one  each  in  Estelle  and  LOTOS;  both  will  be  progressed  as 
informative  annexes  to  the  TP  protocol.  TP  activity  will  be  conducted  in  coordination  with  work 
on  RDA  (SC21/WG3)  and  Application  Layer  standards  (SC21/WG6). 

9.11.9.4  TP  Profiles 

The  ISP  for  TP  (ISO/IEC  12061)  specifies  die  options  (interoperability  parameters) 
required  to  build  a  conformant  TP  application.  It  specifies  not  only  how  the  TP  and  CCR  base 
standards  are  used  but  also  how  to  construct  conformant  Application,  Presentation,  and  Session 
Layers  for  interconnection. 

ISO/IBC 12061,  ISPs  ATP  nn  -  OSI  Distributed  Transaction  Processing,  has  the  following 
13  parts,  of  which  the  first  8  have  reached  DIS  status: 

•  DISP 12061-1.  Part  1:  Introduction,  1993 

•  DISP  12061-2,  Put  2:  Support  of  the  OSI  TPAPDUs,  1993 

•  DISP  12061-3,  Part  3:  Support  of  the  CCR  Protocols,  1993 

•  DISP  12061-4,  Part  4:  Support  ofACSE,  Presentation  and  Session  Protocols,  1993 

•  DISP  12061-5,  Part  5:  ATP  11,  Application  Supported  Transactions  with  Polarized 
Control,  1993 

•  DISP  12061-6,  Part  6:  ATP  12,  Application  Supported  Transactions  with  Shared 
Control,  1993 

•  DISP  12061-7,  Part  7:  ATP  21,  Provider  Supported  Transactions  in  Unchained  Mode 
with  Polarized  Control,  1993 

•  DISP  12061-8,  Part  8:  ATP  22,  Provider  Supported  Transactions  in  Unchained  Mode 
with  Shared  Control,  1993 

•  pDISP  12061-9,  Part  9:  ATP  31,  Provider  Supported  Transactions  in  Chained  Mode 
with  Polarized  Control,  1993 
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•  pDISP  12061*10,  Put  10:  ATP  32.  Provider  Supported  Transactions  in  Chained 
Mode  with  Shared  Control,  1993 

•  pDISP  12061*1 1,  Part  11:  TP  Transaction  Recovery  Application  Context,  1993 

•  pDISP  12061-x,  Part  x:  Systems  Profiting  far  TP,  1993 

•  pDISP  12061-y,  Part  y:  Development  ofPTSfor  TP,  1993 

•  EWOS/TA/93/083,  ISP  FDI 41,  Directory  Data  Definitions  -  Use  of  Directory  far  OSI 
TP,  Part  1:  Basic  Naming  and  Addressing,  October  1993 

•  EWOS/TA/93/084,  ISP  FDI  42,  Directory  Data  Definitions  -  Use  of  Directory  far  OSI 
TP,  Part  2:  Enhanced  Naming  and  Addressing,  October  1993. 

9.11.9.5  TP  New  Work  Items 

Table  28  identifies  the  new  work  items  that  have  been  proposed  for  TP.  Work  has  began 
on  TP  association  pool  management  (formerly  called  association  management).  It  is  WD  10026-x, 
TP  Association  Pool  Management  Function,  Working  Draft,  SC21  N  7604,  2  February  1993. 
Association  management  is  concerned  with  manipulation  and  query  of  management  information 
corresponding  to  an  association  and  its  relationships  with  supporting  connections.  [Ref. 
SC21N7417  1992] 


Tablu  28.  Now  Work  Items  Proposed  In  ISO  for  TP 


_ _  provide  for  mo  management  of  appHcsHon  associations  in  a 

distributed  proosssinfl  environment  Invoking  muSipie  open  ayetomo  [SC21  N  5177].  OkltMewaeTP 
Association  Management.  WD  10026-x  TP  Association  Pool  Management  Function  [SC21  N  7804, 
February  1963] 

1°  fhalpg***  P**r"u^n*-- the  third  phase  of  recovery  (as  defined  in  IS0 10026-1);  I  is  requited  to  enable 
Transaction  Processing  Service  User  Invocations  (TPSUIs)  to  continue  normal  operation  Mowing  the 
re  establshmsnt  of  bound  data  conaMancy  [SC21  N  4170V  h  WD  was  produced  tot  January  1992 
[SCSI  N  6710].  CD  tart  was  expected  in  June  1993,  DIS  in  June  1994,  and  IS  in  June  1996. 

TP  Heuristic  rwtatwM  advisory  propagation  of  a  heuristic  decision  to  al  nodes;  advisory 

propagation  to  nodes  in  the  subtree  below  the  node  taking  the  heuristic  decision;  mandatory 
propagation  of  a  heuristic  decision  to  al  nodes;  and  mandatory  propagation  to  nodoe  in  the  subtree 
below  the  node  taking  the  heuristic  decision  [SC21  N4167],  PROJECT  CANCELLED  in  June  1993. 

TP  Savepoints  service  to  enabio  a  transaction  to  be  able  to  save  and  later  restore  a  consistent  stale 
of  al  bound  data  under  Is  control  (SC21  N  4171$  new  work  item  not  accepted  by  JTC1,  June  1990. 

TP  Security— considers  requirements  for  provision  of  a  secure  environment  tor  TP  in  areas  such  as 
access  control,  auditing,  authentication,  confidentiality,  integrity,  management,  nonrepudtetion, 
replay,  and  revocation  [SC21  N  5176,  approved  June  1990].  In  the  absence  of  an  Edfeor  and  WD. 
SC21  is  recommending  cancelation  of  this  project 

TP  Subtrap— -extensions  to  TP  that  would  provide  partial  roitoack  and  nested  transactions 
[SC21  N  6236].  in  the  current  TP  standard  (ISO  10026),  al  the  bound  data  that  are  invoked  in  a 
transaction  tree  tor  a  transaction  are  committed  together  and,  I  the  transaction  fate,  al  the  bound 
data  are  rated  back.  In  the  absence  of  an  Edkor  and  WD,  SC21  is  racommendtog  cancelation  of  this 
prefect 

TP  Drta  end  P— -»  ««  ^*y  <no,l  Amendments  to  Parts  1. 2, 

3.  and  4.  PD  AMs  expected  June  1994,  DAM  in  June  1995,  and  AM  in  June  1996.  SC21  N  7166,  May 
1 992,  Requirements  and  issues  for  the  Separation  of  Data  and  Oomml  Flows  in  OSi-TP. 

TP  Conformance  Teatino.  A  two-part  standard.  WD  on  Tost  Suite  Structure  and  Teat  Purposes 
(TSSTP)  [SC21  N  6216}.  Second  part  is  Test  Management  Protocol  (TMP). 


196P-SC21 


An  Association  Pools  Requirements  and  Requirements  Issues  [SC21  N  6698]  document 
was  tiie  output  of  discussions  held  at  the  TP  Rapporteur's  meeting  in  November  1991.  The 
Discussion  Paper  on  Association  Pools  as  an  Extension  ofACSE,  April  1991  [SC21  N  5835], 
provides  a  possible  overall  approach  for  the  NWI  covering  TP  Association  Pool  Management  A 
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discussion  paper,  Strawman  Design :  TP  Association  Pools  [SC21/WG5  N  660],  was  issued  in 
May  1992  to  progress  the  work.  SC21/WG6  has  identified  a  number  of  issues  related  to  the 
project  that  are  discussed  in  [SC21  N  7168,  June  1992]. 

A  new  work  item  on  TP  security  [SC21  N  6232,  July  1991]  is  intended  to  expand  the  TP 
model,  service,  and  protocol  (ISO  10026-1,2,3)  to  provide  a  secure  environment  for  distributed 
transaction  processing  interactions  involving  multiple  open  systems.  PDAD  text  is  expected  in 
1993,  DAD  in  1994,  and  AD  in  1993.  In  a  March  1992  communication  to  WG3 
[SC21/WG5  N  633],  the  United  States  suggested  that  in  light  of  the  Security  Exchange  Service 
Element  (SESE)  being  defined  by  WG6  (see  Section  11.2.2.4)  it  is  unnecessary  to  develop  a 
complete  TP  Security  Model,  as  many  of  the  security  threats  perceived  by  users  of  OSI  TP  may  be 
counteracted  Suites.  Thus,  the  United  States  proposed  that  the  TP  Security  Model  be  refined  to 
only  reflect  the  security  services  that  need  to  be  provided  directly  by  OSI  TP,  namely  entity 
authentication,  access  control,  and  non-repudiation.  In  the  absence  of  an  Editor  and  WD,  SC21  is 
recommending  cancellation  of  the  project 

In  September  1993,  WG3  issued  a  revised  Working  Draft  for  a  Conformance  Test  Suite  for 
dte  TP  Protocol,  Part  1,  Test  Suite  Structure  (TSS)  and  Test  Purposes  (TP)  [SC21  N  8216]  for 
study  and  comment  This  NWI  was  accepted  into  the  JTC1  work  program  and  an  Initial  Abstract 
Test  Suite  for  TP  was  produced  in  November  1992.  [Ref.  SC21  N  7676  1993]  Part  2  is  TP  Test 
Management  Protocol  (TMP). 

Two  approaches  are  being  considered  for  using  RPC  and  TP  together 
[Ref.  SC21  N  5172  1990]: 

•  With  RPC  as  the  data  transfer  paradigm  for  TP,  with  use  being  made  of  TP  dialogue 
management  functions 

•  Using  TP  commitment  functionality  to  complement  the  operation  of  RPC-based 
services  (without  necessarily  making  use  of  TP  dialogues)  to  support  "exactly  once" 
semantics. 

A  liaison  paper  on  TP  with  RPC  [SC21  N  8067]  was  distributed  in  July  1993,  which  called  for 
comments  on  the  integration  of  RPC  with  TP,  since  many  users  need  an  RPC  with  transactional 
semantics.  In  October  1993,  the  US  response  to  this  paper  suggested  that  instead  of  beginning  a 
new  standardization  effort  for  transactional  RPC,  SC21/WG8  may  wish  to  fast-track  X/Open’s 
TxRPC  specification.  TxRPC  is  an  interface  to  a  communications  resource  manager  that  is 
predicated  on  die  use  of  OSI  TP. 

In  1989  a  potentially  serious  problem  was  identified  for  TP.  Under  certain  circumstances, 
protocol  exchanges  from  one  transaction  (such  as  rollback)  could  overtake  those  outstanding  from 
a  previous  transaction  (and  could  therefore  be  interpreted  by  the  receiving  node  as  pertaining  to  the 
previous  transaction).  This  can  occur  if  lower  layer  expedited  services  are  used  to  convey 
particular  PDUs.  The  interim  solution  that  was  adopted  was  to  avoid  the  use  of  Transport 
expedited  data  transfer  services.  This  issue  has  raised  the  possible  requirement  for  a  Non- 
Blocking  Transport  Expedited  Service.  A  June  1991  US  Expert's  Paper  [SC21/WG4  N  721] 
outlined  one  solution  for  non-blocking  transport  expedited  service.  However,  the  TP  Rapporteur 
Group  believes  that  such  a  service  is  unnecessary  and  undesirable  because  of  its  effects  on 
dependent  upper  layer  services.  [Ref.  SC21  N  7175  1992] 

In  October  1993,  the  US  national  body  identified  a  requirement  for  partial  roll  back  of  a 
transaction  within  die  OSI  TP,  wherein  a  transaction's  branches  may  be  rolled  back  in  a  transaction 
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that  is  eventually  committed.  Branches  may  need  to  be  rolled  back  as  a  result  of  either  the 
occurrence  of  certain  types  of  branch  failure  or  from  requests  by  superior  nodes  to  undo  branch 
operations.  {Ref.  SC21 N  8321  1993] 

9.11.10  OSI  Information  Retrieval  (IR)54 

The  OSI  Information  Retrieval  (IR)  application  supports  the  open  interconnection  of 
information  clients  with  information  servers  by  specifying  an  OSI  application  layer  protocol  for 
intersystem  search  and  retrieval  of  information.  IR  addresses  retrieval  (but  not  update)  of 
information,  and  the  IR  protocol  specifies  basic  information  retrieval  operations,  a  common  syntax 
for  queries  and  the  means  to  express  their  semantics,  and  the  means  to  allow  the  partner  systems  to 
share  an  understanding  of  the  information  retrieved.  The  IR  protocol  provides  access  to 
information  resources  without  requiring  servers  to  structure  databases  similarly  or  to  name  fields 
within  record  structures  similarly.  It  provides  the  means  to  register  attribute  set  definitions  that 
express  the  semantics  of  information  exchanged.  The  standard  supplies  a  basic  attribute  set  for 
search  and  retrieval  of  text-based  information. 

The  standards  for  IR  are  the  following: 

•  ISO/IEC  8777,  Information  and  Documentation  -  Commands  for  Interactive  Text 
Searching,  1993 

•  ISO/IEC  10162,  Information  and  Documentation  -  Search  and  Retrieve  Application 
Service  Definition  for  Open  Systems  Interconnection 

•  ISO/IEC  10163,  Information  and  Documentation  -  Search  and  Retrieve  Application 
Protocol  Specification  for  Open  Systems  Interconnection 

•  ANSI  Z39.50-MA-26,  Implementor’s  Group  Profile. 

Profiles  for  IR  need  to  specify  such  options  as  whether  it  applies  to  the  client,  the  server,  or 

both. 

9.12  Internetworking 

9.12.1  General  Interworking  Standards 

The  basic  interworking  standards  used  for  specifying  relays  arc  the  following  (examples  of 
relay  profiles  using  these  standards  are  given  in  Appendix  B): 

•  ISO/IEC  10028-1,  Definition  of  the  Relaying  Functions  of  a  Network  Layer 
Intermediate  System,  Part  1:  Connection-mode  Network  Service,  1993 

PD  AM  1,  Connectionless  Mode  Relaying  Functions,  February  1991 

•  ISO/IEC  10028-2,  Definition  of  the  Relaying  Functions  of  a  Network  Layer 
Intermediate  System,  Part  2:  Connectionless  Network  Service,  1993 

•  ISO/IEC  TR  10029,  Operation  of  an  X.25  Interworking  Unit,  March  1989 

•  ISO/IEC  10030,  End  System  to  Intermediate  System  Routing  Information  Exchange 
Protocol  for  Use  in  Conjunction  with  ISO/IEC  8878  (X.25  PLP)  [SC6  N  5006], 
October  1990 

PD  AM  1,  Dynamic  Discovery  of  OSI  NASP  Addresses  by  End  Systems 
-  AM  2,  PICS  Proforma,  1992  (see  DIS  10030-2) 

PD  AM  3,  Specification  qfIS-SNARE  Interactions,  August  1991 


34  ThU  section  is  based  on  excerpts  from  [KSOSS 1993]. 
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•  DIS  10030-2,  End  System  to  Intermediate  System  Routing  Information  Exchange 
Protocol  for  Use  in  Conjunction  with  ISO/IEC  8878  (X.25  PLP),  Part  2:  PICS 
Proforma,  October  1991 

•  DIS  10038,  Local  Area  Networks  -  MAC  Sublayer  Interconnection  (MAC  Bridging) 
(awaiting  DIS  ballot),  December  1991 

PD  AM  1,  Specification  of  Management  Information  for  CM1P 
-  DAM  2,  Source  Routing  Supplement,  October  1991 

•  ISO/IEC  10177,  Intermediate-System  Support  of  the  OSI  Connection-Mode  Network 
Service  Using  ISO  8208  in  Accordance  with  ISO  10028 

•  ISO/IEC  10589,  Intermediate  System  to  Intermediate  System  Routing  Information 
Exchange  Protocol  for  Use  in  Conjunction  with  ISO  8473 

•  DIS  10747,  Protocol  for  Exchange  of  Inter-Domain  Routing  Information  Among 
Intermediate  Systems  to  Support  Forwarding  of  ISO  8473  PDUs. 

ANSI  X3S3  has  Ihiee  MAC-related  liaison  projects  with  JTC1/SC6  underway; 

•  To  develop  a  technical  report  that  will  provide  a  description  of  the  representation  of 
MAC  Addresses.  The  report  will  record  all  values  assigned  for  die  use  of  Standards  in 
one  document,  whereas  at  present  this  information  is  scattered  across  a  number  of 
documents.  [Ref.  X3  1991b] 

•  To  develop  an  amendment  to  DIS  10038  that  will  extend  the  scope  to  include  source 
routing  capability.  [Ref.  X3  1991c] 

•  To  develop  a  technical  report  that  will  provide  guidelines  for  LANs  implementing 
"source  routing  operation”  defined  in  DIS  10038/DAM  2,  MAC  Bridging  -  Source 
Routing  Supplement,  October  1991.  [Ref.  X3  1991d] 

TR  10172,  Network/Transport  Protocol  Interworking  Specification,  October  1990 
[SC6  N  5906,  March  1990],  addresses  the  inability  of  end  systems  operating  in  the  CO  network 
protocol  (ISO  8208/8878  X.25)  and  CL  network  protocol  (ISO  8473)  to  interwork  with  each 
other.  A  mediating  device,  called  the  Interworking  Functional  Unit  (IFU),  is  defined  to  perform 
relaying  and/or  conversion  of  protocol  data  units  (PDUs)  from  one  network  protocol  type  to 
another.  Three  modes  of  operation  are  considered  in  TR  10172: 

•  Network  Laver  Relay  (NLRL  In  the  NLR  mode  the  IFU  operation  functions  as  a 
regular  intermediate  system.  CL  NLR  operation  is  in  accordance  with  ISO  8473  and 
CO  NLR  with  ISO  10177  and  ISO  10028. 

•  Passive  Transport  I  .aver  Rdav  fPTLR).  PTLR  does  not  itself  operate  on  the  PDUs  of 
transport  connections,  but  passes  transport  PDUs  received  in  network  service  data 
units  from  each  end  system  transparently  to  the  other  end  system. 

•  Active  Transport  Laver  Relay  (ATLR1.  ATLR  provides  an  end-to-end  transport 
service  by  operating  a  separate  transport  connection  to  each  of  the  connected  end 
systems  and  relaying  data  from  one  connection  to  the  other. 

Since  the  PTLR  and  ATLR  modes  of  operation  lie  outside  the  scope  of  the  OSI 
architecture,  the  technical  report  is  not  planned  to  be  converted  to  an  ISO  standard. 

Network  Relay  (also  called  Routing),  however,  is  the  most  important  outstanding  issue  in 
the  Network  Layer.  The  standards  that  describe  the  protocols  and  algorithms  for  routing  over  a 
connectionless  network  service  have  progressed  rapidly  over  the  last  3  to  4  years,  after  a  slow 
start,  but  final  standards  and  products  that  implement  diem  have  started  appearing.  T*e  equivalent 
work  on  touting  for  connection-oriented  networks  has  proceeded  more  slowly,  ami  it  is  not  clear 
when  draft  standards  will  be  published.  Examples  of  network  relay  profiles  appear  at  the  end  of 
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Appendix  B.  Four  OSI  standards  are  of  particular  importance  to  the  provision  of  open  routing 
[Ref.  OSN  1990b]: 

•  ISO  8473,  Protocol  for  Providing  Connectionless-Mode  Network  Service 

•  ISO  9S42.  End  System  to  Intermediate  System  ( ES-IS)  Routing  Exchange  Protocol 

•  ISO/IEC  10S89,  Intermediate  System  to  Intermediate  System  (IS-IS)  Intra-domain 
Routing  Exchange  Protocol,  1992 

•  DIS  10747,  Protocol  for  Exchange  of  Inter-domain  Routing  Information  Among 
Intermediate  Systems  to  Support  Forwarding  of  ISO/IEC  8473  PDUs,  1993 

EWOS  has  released  a  Technical  Guide  to  Routing  in  the  Context  of  OSI,  EWOS- 
EGLL/91/72  [IST/21:2860],  May  1991. 

Task  Group  ANSI  X3S3.7  of  Accredited  Standards  Committee  (ASC)  X3S3,  Data 
Communications,  is  developing  a  draft  standard  describing  the  interworking  between  two  packet 
switched  data  networks  (PSDNs)  via  an  X.25  link.  This  draft  standard  (Project  682-D)  would 
typically  be  used  for  interworking  between  a  packet  switched  public  data  network  (PSPDN)  and  a 
packet  switched  private  data  network  (PSPvtDN).  It  specifies  the  general  addressing  and  routing 
principles  associated  with  two  PSDNs  and  their  interworking  as  well  as  the  procedures  to  be 
followed  by  an  interworking  function  (IWF)  that  is  used  to  connect  the  PSPDN  and  the  PSPvtDN. 
[Ref.  X3  1991e] 

The  following  comment  on  CL-mode  and  CO-mode  interworking  was  provided  to  SC21 
following  a  February  1990  meeting  of  ITU-TS  SG  VII  regarding  the  proposed  update  to  the  OSI 
Reference  Model  (ISO  7498-1)  [Ref.  SC21  N  4559  1990]: 

The  connectionless/connection-mode  crossover  rules  currently  proposed  by  ISO 
appeared,  to  many  of  the  Q23/VII  attendees  at  this  meeting,  to  be  unacceptable  for 
use  in  fully  supporting  connectionless-mode  ITU-TS  applications,  due  mainly  to 
interconnectivity  problems.  Many  of  die  attendees  felt  that,  for  "across-the-board" 
support  of  connectionless  ITU-TS  applications,  within  the  lower  layers,  there  is  a 
need  to  have  common  (mandatorily  provided)  support  required  that  would  assure 
interconnectivity  among  all  connectionless-mode  OSI  ITU-TS  applications.  It  was 
unanimously  agreed  that  die  concept  of  attempting  to  solve  such  interconnection 
problems  exclusively  through  introduction  of  any  "transport  relay"  concept  in 
ITU-TS  Recommendations  is  totally  unacceptable. 

Technical  Committee,  ANSI  X3.T6,  Non-Contact  Information  Systems  Interface  (NC3SI), 
is  developing  a  non-contact  standard  interface  between  computer  devices  for  the  transfer  of 
information.  The  committee  is  developing  a  standard  for  US  activities;  however,  it  eventually 
intends  the  standard  to  be  submitted  to  ANSI  as  a  JTC1  .Fast  Track  Candidate  for  approval  as  an 
international  standard.  The  committee  will  review  current  technology  in  radio  frequency 
data/communication,  infrared,  and  similar  non-contact  data  transfer  technologies  with  the  objective 
of  standardizing  the  interface  between  like  devices.  The  standard  would  be  restricted  to  the 
interface,  allowing  unrestricted  development  of  computer  components  on  either  side  of  the 
interface.  [Ref.  X3  1991f] 

Task  Group  X3S3.7  of  ASC  ANSI  X3S3,  Data  Communications,  has  begun  an  effort  to 
develop  a  standard  to  be  used  in  conjunction  with  frame  relay  standards.  It  could  be  used  in  other 
cases  where  X.25  virtual  circuit  (VC)  establishment  and  clearing  procedures  and  other 
non- VC-specific  procedures  are  not  needed.  This  standard  will  be  a  subset  of  Recommendation 
X.25  and  ISO  8208.  [Ref.  X3  1991g] 
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9.12.2  Relay  ISPs  (R-Prnflles) 

Table  29  lists  the  relay  profiles  currently  being  standardized  by  ISO  as  ISPs. 


Table  29.  Relay  Profiles  Standardized  by  ISO 

CUSP  10612*1  ISl*s  RD  nn.nn,  Part  1:  RD  5p.5q  Profile.  Relaying  MAC  Using  Transparent  Bridging  - 
General  Overview  and  Subnetwork-Independent  Requirements,  1993 
DISP  10612*2  ISPs  RD  nn.nn.  Part  2:  RD  5p.5q  Profile.  Relaying  MAC  Using  Transparent  Bridging  • 
CSMA/CD  LAN  Subnetwork-Dependent  Meda-lndependent  Requirements,  1993 
pOISP  10612-3  ISPs  RD  nn.nn,  Part  3:  RD  5p.5q  Profile,  Relaying  MAC  Using  Transparent  Bridging  • 
CSMA/CD  LAN  Subnetwork-Dependent  Media-Dependent  Requirements,  1993 
DISP  10612-4  ISPs  RD  nn.nn,  Part  4:  RD  51.51  Profile,  MAC  Service  Relay  Using  Transparent  Bridging, 
CSMA/CD  LAN  -  CSMA/CD  LAN,  1993 

pOISP  10612-5  ISPs  RD  nn.nn,  Part  5:  TO  51.54  Prof ie,  MAC  Service  Relay  Using  Transparent  Bridging, 
CSMA/CD  LAN  -  FDOt  LAN.  1993 

pDISP  10612-6  ISPs  TO  nn.nn,  Part  6:  TO  54.54  Profle,  MAC  Service  Relay  Using  Transparent  Bridging. 
FDCN  LAN  -  FDOI  LAN,  1993 

pDISP  10612-7  ISPs  RD  nn.nn,  Part  7:  TO  51.53  Profle,  MAC  Service  Relay  Using  Transparent  Bridging, 
CSMA/CD  LAN  -  Token  Ring  LAN,  1993 

pDISP  10612-8  ISPs  TO  nn.nn,  Part  6:  TO  53.53  Profile,  MAC  Service  Relay  Using  Transparent  Bridging, 
Token  Ring  LAN  -  Token  Ring  LAN,  1993 

pDISP  10612-9  ISPs  TO  nn.nn.  Part  9:  TO  53.54  Profile,  MAC  Service  Relay  Using  Transparent  Bridging, 
Token  Ring  LAN  •  FDOI  LAN,  1993 

pDISP  10613-1  ISPs  RA  nn.nn  •  Relaying  the  Connectionless-mode  Network  Service,  Part  1:  Relay 
Function,  Overview,  Subnetwork-Independent  Requirements.  1993 
pDISP  10613-2  ISPs  RA  nn.nn  •  Relaying  the  Connectionless-mode  Network  Service,  Part  2:  LAN 
Subnetwork-Dependent.  Meda-lndependent  Requirements.  1993 
pOISP  10613-3  ISPs  RA  nn.nn  -  Relaying  the  Connectionless  mode  Network  Sendee.  Part  3:  CSMA/CD  LAN 
Subnetwork-Dependent  Meda-Dspendsnt  Requirements,  1993 
DISP  10613-4  ISPs  RA  nn.nn  •  Relaying  the  Connectionless-mode  Network  Service,  Part  4:  FDDI  LAN 
Subnetwork-Dependent  Meda  Dependant  Requirements.  1993 
pDISP  10613-5  ISPs  RA  nn.nn  -Relaying  the  Connectionless-mode  Network  Service.  Part  5:  RA51.51 
Profile,  CSMA/CD  LAN  -  CSMA/CD  LAN,  1993 

pDISP  10613-6  ISPs  RA  nn.nn  -Relaying  the  Connectionless-mode  Network  Service,  Part  6:  RA51.54 
Profile,  CSMA/CD  LAN  -  FDDI  LAN,  1993 

pDISP  10613-7  ISPs  RA  nn.nn  -  Relaying  the  Connectionless-mode  Network  Service,  Part  7:  PSDN 
Subnetwork  Meda  Dependent  VC  Permanent  Access,  1993 
pDISP  10613-8  ISPs  RA  nn.nn  -  Relaying  the  Connectionless-mode  Network  Service,  Part  8:  RA51 .1 1 1 1 
Profile,  1993 

pDISP  10613-9  ISPs  RA  nn.nn  -  Relaying  the  Connectionless-mode  Network  Service,  Part  9:  RA51.1 121 
Profile.  1993 

pDISP  10614-1  ISPs  RC  nn.nn  -  Relaying  X.25  PLP,  Part  1:  General  Overview  and  Subnetwork  Independent 
Requirement  1993 

pDISP  10614-2  ISPs  RC  nn.nn  •  Relaying  X.25  PLP,  Part  2:  LAN  Subnetwork  Dependent  Meda  Independent 
Requirement  1993 

pDISP  10614-3  ISPs  RC  nn.nn  •  Relaying  X.25  PLP,  Part  3:  CSMA/CD  LAN  Subnetwork  Dependent  Media 
Dependent  1993 

pDISP  10614-4  ISPs  RC  nn.nn  -  Relaying  X.25  PLP,  Part  4:  PSDN  Subnetwork  Type  Dependent 
Requirement  1993 

DISP  10614-5  ISPs  RC  nn.nn  -  Relaying  X25,  Part  5:  RC51.1111,  CSMA/CD  -  PSDN  Permanent  Access 
PSTN-Leased  Virtual  Circuit,  1993 

DISP  10614-6  ISPs  RC  nn.nn  •  Relaying  X.25,  Part  6:  RC51.1 121,  CSMA/CD  -  PSDN  Permanent  Access 
_ CSDN-Leased  Virtual  Circuit  1993. _ 


9.12.3  Routing  (Transport)  ISPs  (T-Profiles) 

Table  30  lists  the  relay  profiles  currently  being  standardized  by  ISO  as  ISPs.  Because  of 
the  large  number  (48)  of  parts  to  ISP  10609,  the  table  shows  only  Parts  1-14  and  those  parts 
beyond  Part  14  that  have  reached  DISP  status.  Others  may  be  found  in  Appendixes  D  and  E 
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Tab)*  30.  Transport  Proflkw  Standardized  by  ISO 


10606-1  ISPs  TA  nnnn  •  Connection-mods  Transport  Service  over  Connect!  on  less- mode 
Network  Service  (COTS  over  CONS).  Part  1:  General  Overview  and  Subnetwork- 
Independent  Requirements,  1992 

ISO/IEC  ISP  10608-2  ISPs  TA  nnnn  -  COTS  over  CONS,  Part  2:  TAS1  Profile  Including  Subnetwork- 
dependent  Requirements  for  CSMA/CD  Local  Area  Networks,  1992 
DiSP 10608-3  ISPs  TA  nnnn  -  COTS  over  CONS,  Part  3:  TA  52.  LAN.  Token  Bus:  CLNS 
ISO/IEC  ISP  10608-4  ISP  TA  nnnn  •  COTS  over  CONS,  Part  4:  TA53  COTS  over  CLNS.  LICI,  Token  Ring  LAN 

ISO/IEC  ISP  10608-5  ISPs  TA  nnnn  -  COTS  over  CONS,  Part  5:  TA1111/TA1121  Profiles  Including 

Subnetwork-dependant  Requirements  for  X.25  Packet  Switched  Data  Networks  Using 
Switched  Virtual  Circuits,  1992 

DiSP  1 0608-6  ISPs  TA  nnnn  -  COTS  over  CONS,  Part  6:  TA54  Profile 

DiSP  10608-13  ISPs  TA  nnnn  •  COTS  over  CONS,  Part  13:  LAN-Dependent  Requirements  for  Token  Ring 
MAC  and  PHY 

DISP  10608-14  ISPs  TA  nnnn  -  COI J  over  CONS,  Part  14:  MAC,  PHY.  PMD  Sublayer  Dependent  State 
Management  Requirement  Over  FDDI  LAN  Subnetwork 

ISO/IEC  ISP  10609-1  ISPs  TB,  TC,  TD,  and  TE  -  COTS  over  CONS,  Part  1:  Subnetwork-type  Independent 
Requirements  for  Group  TB,  1 992 

ISO/IEC  ISP  10609-2  ISPs  TB,  TC,  TD,  and  TE  -  COTS  over  CONS,  Part  2:  Subnetwork-type  Independent 
Requirements  for  Group  TC,  1 992 

ISO/IEC  ISP  10609-3  ISPs  TB,  TC,  TD,  and  TE  -  COTS  over  CONS,  Part  3:  Subnetwork-type  Independent 
Requirements  for  Group  TD,  1992 

ISO/IEC  ISP  10609-4  ISPs  TB,  TC,  TD,  and  TE  •  COTS  over  CONS,  Part  4:  Subnetwork-type  Independent 
Requirements  for  Group  TE,  1992 

ISO/IEC  ISP  10609-5  ISPs  TB,  TC,  TD,  and  TE  -  COTS  over  CONS,  Part  5:  Definition  of  Profile  TB  1 1 1 1/TB 

1121, 1992 

ISO/IEC  ISP  10609-6  ISPs  TB,  TC,  TD,  and  TE  •  COTS  over  CONS,  Part  6:  Definition  of  Profile  TC  1 1 1 1/TC 

1121,1992 

ISO/IEC  ISP  10609-7  ISPs  IB.  TC,  TD,  and  TE  -  COTS  over  CONS,  Part  7:  Definition  of  Profile  TD  1 1 1 1/TD 

1121,1992 

ISO/IEC  ISP  10609-8  ISPs  TB.  TC,  TD.  and  TE  -  COTS  over  CONS,  Part  8:  Definition  of  Profile  TE  1111/TE 

1121,1992 

ISO/IEC  ISP  10609-9  ISPs  TB,  TC.  TD,  and  TE  -  COTS  over  CONS.  Part  9:  Subnetwork-type  Dependent 
Requirements  for  Network  Layer,  Data  Link  Layer,  and  Physical  Layer  Concerning 
Permanent  Access  to  a  Packet  Switched  Data  Network  Using  Virtual  Call,  1992 
pOISP  10609-10  ISPa  TB.  TC.  TD.  and  TE  -  COTS  over  CONS,  Part  10. 1993 

pDISP  10609-1 1  ISPs  TB.  TC.  TD,  and  TE  -  COTS  over  CONS  Part  1 1, 1993 

pOISP  10609-12  ISPs  TB,  TC.  TD,  and  TE  -  COTS  over  CONS,  Part  12:  TC51  Profile,  1993 

pDISP  10609-13  ISPs  TB.  TC,  TD,  and  TE  -  COTS  over  CONS.  Part  13:  TC53  Profile.  1993 

pOISP  10609-14  ISPs  TB,  TC,  TD,  and  TE  •  COTS  over  CONS,  Part  14:  COTS  Ciassee  0  and  2.  CONS,  LLC2, 

Token  Ring  LAN,  1993 

DiSP  1 0609-31 •  ISPs  TB.TC.TD,  and  TE- COTS  over  CONS,  Part  31:  TC  1 231 ,  ISDN  B-Channel  Virtual  Cal, 

Switched  Access  to  a  PSDN,  1993 

DISP  10609-32*  ISPs  TB,  TC,  TD,  and  TE  -  COTS  over  CONS,  Part  32:  TC  41 1 1 ,  ISDN  B-Channel  X25  DTE 

to  DTE,  Semi-permanent  Service,  1993 

DISP  10609-33*  ISPs  TB,  TC,  TD,  and  TE  -  COTS  over  CONS,  Part  33:  TC  4112,  ISDN  B-Channel  X25  DTE. 
Circuit-mode  Service,  1993 

DISP  10609-34*  ISPs  TB,  TC.  TD,  and  TE  -  COTS  over  CONS,  Part  34:  TC  431 1 1 .  ISDN  D-Channel  Access 
Virtual  Can,  Packet-mode  Service,  Without  Q.931, 1993 

DISP  10609-35*  ISPs  TB.  TC.  TD.  and  TE  -  COTS  over  CONS,  Part  35:  TC  43112,  ISDN  D-Channel  Accesa 
Virtual  Call,  Packet-mode  Service,  with  Q.931, 1993 

DISP  10609-36*  ISPs  TB,  TC,  TD,  and  TE  -  COTS  over  CONS,  Part  36:  TC  43211,  ISDN  B-Channel 
Permanent  Access  Virtual  Call,  Packet-mode  Sendee,  Without  Q.931, 1993 
DISP  10609-37*  ISPs  TB,  TC,  TD,  and  TE  -  COTS  over  CONS,  Part  37:  TC  43212,  ISDN  B-Channel 
Permanent  Access  Virtual  Cal,  Packet-mode  Service,  with  Q.931, 1993 
DiSP  10609-38*  ISPs  TB,  TC.  TD,  and  TE  -  COTS  over  CONS,  Part  38:  TC  4331 .  ISDN  B-Channel  Demand 
_ Access  Virtual  Cal,  Packet-mode  Service,  1993 


Note:  pDISPs  1 0609  (Parts  20-30  and  40-48)  are  omitted  from  this  table  but  included  in  Section  I.H  of  Appends  D 
and  in  Appendix  E  (only  the  those  parts  beyond  Part  1 4  that  Itave  reached  DISP  status  are  shown  in  the  table). 


pOISP  10609-10 
pDISP  10609-11 
pDISP  10609-12 
pDISP  10609-13 
pOISP  10609-14 

DISP  10609-31* 

DISP  10609-32* 

DISP  10609-33* 

DISP  10609-34* 

DISP  10609-35* 

DISP  10609-36* 

DISP  10609-37* 

DiSP  10609-38* 
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9.13  Other  Standards  and  Issues 

9.13.1  Time  Synchronization 

ITU-TS  SG  VII(Q19)  has  begun  work  on  a  time  synchronization  service  (TSS).  The  work 
is  based  on  the  US  DoD  RFC-1 1 19,  Network  Time  Protocol  (NTP),  currently  being  used  by  the 
Internet  community  (see  Section  9.7.4).  The  TSS  time  standard  is  based  on  the  Coordinated 
Universal  Time  (UTC),  determined  by  the  Bureau  International  de  1'Heure  (BIH)  from 
astronomical  observations  provided  by  the  US  Naval  Observatory  and  other  observatories.55 

The  TSS  can  be  used  in  distributed  systems  in  several  ways:  to  measure  elapsed  time,  to 
preserve  tire  order  of  events,  and  to  coordinate  activities  of  a  set  of  processes.  The  elements  of  the 
TSS  model  are  the  following: 

‘  •  Local  clock — an  oscillator  that  once  set  with  a  time  value,  attempts  to  maintain  a  local 

estimate  of  global  time 

•  Time  user  agent  (TUA) — the  user  of  the  TSS 

•  Time  synchronization  agent  (TSA) — the  provider  of  the  service. 

Each  TUA  interacts  with  a  set  of  TSAs  to  obtain  information,  from  this  information  to 
determine  the  best  estimate  of  global  time,  and  to  set  the  local  clock  to  this  value.  The  TUA  may 
adjust  the  frequency  of  the  local  clock  to  compensate  for  drift  in  the  hardware.  Synchronization  of 
clocks  is  by  continuous  distribution  of  time — TUAs  build  up  information  based  on  samples  of  a 
number  of  servers  for  the.  delay  characteristics  of  tire  communication  path  between  itself  and  each 
of  the  TSAs. 

Time  is  distributed  through  the  system  via  a  hierarchical  set  of  TSAs.  Stratum  1  TSAs,  at 
the  top  of  the  hierarchy,  have  local  clocks  that  are  set  by  external  means  from  the  most  accurate 
sources  available.  These  means  could  include  radio  receivers  and  such  satellite  devices  as  the 
Global  Positioning  System.  Clocks  that  have  been  set  by  TUAs  that  have  obtained  time 
information  directly  from  Stratum  1  TSAs  are  said  to  be  at  Stratum  2.  At  each  level  of  the 
hierarchy,  except  the  top  and  bottom,  each  TUA  may  have  an  associated  TSA  that  can  be  used  to 
distribute  time  information  in  the  local  clock  to  TUAs  at  tire  next  lowo-  level  of  the  stratum.  It  is 
expected  that  there  will  be  a  number  of  Stratum  1  TSAs,  some  being  provided  as  public  services. 
Each  site  using  LANs  would  have  two  or  more  Stratum  2  TSAs,  and  each  LAN  segment  could 
have  two  or  more  Stratum  3  TSAs.  Individual  end  systems  might  not  need  to  have  clocks  at  much 
more  than  Stratum  4.  [Ref.  SC21  N  4565  1990] 

A  task  force  has  been  set  up  under  ISO/TC184/SC5/WG2  to  look  at  the  requirements  for  a 
time-critical  communications  architecture  (TCCA)  because  the  network  architectures  set  up  so  far 
are  primarily  intended  for  general  traffic  and  are  not  always  capable  of  providing  adequate 
performance  and  resilience  for  time-critical  communications,  especially  where  time-critical  and 
non-time-critical  traffic  coexist  In  particular,  in  many  CIM  and  control  installations  there  appears 
to  be  a  requirement  for  an  intermediate  network,  between  general  enterprise-wide  networks  (e.g., 
MAP)  and  field-bus-type  networks.  This  intermediate  network  would  carry  both  bulk  data 
transfers  and  time-critical  messages,  and  be  able  to  operate  over  considerable  distances  and  in 
hostile  environments.  A  liaison  between  TC184/SC5/WG2  and  SC21/WG4,  OSI  Management 
[Ref.  SC21  N  5602  1991]  has  been  established.  ANSI  X3.102,  Data  Communication  Systems 


55  Discussion  on  time  synchronization  was  taken  from  SC21  N  4565,  Liaison  Statement  to  SC21/WG4/WG7  on 
Tune  Synchronization,  CCl  l  I  SG  VII,  March  1990. 
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and  Services  User  Oriented  Performance  Parameters,  1983,  Revised  1990,  is  being  uaed  as  a  basis 
for  the  effort  A  key  requirement  of  a  TCCA  is  a  set  of  services  aligned  with  ISO/IEC,  MMS  (see 
Section  9.11.3).  One  aspect  of  Time-Critical  Communications  Systems  (TCCS)  is  Time 
Synchronization. 

In  May  1992,  SC21/WG1  posed  a  new  question  (Ql/65)  on  user  requirements  for  OSI 
systems  supporting  time  critical  communications.  The  question  is,  what  architectural 
enhancements  to  ISO  7498,  if  any,  are  required  to  meet  the  requirements  of  the  TCCA?  The 
Technical  Report  of  the  TTCA  rapporteurs  group  of  TC184/SC5/WG2  identifying  user 
requirements  for  systems  supporting  time  critical  communications  (TR  12178,  December  1993) 
will  be  used  as  a  basis  for  an  answer.  [Ref.  SC21  N  7090  1992]  The  results  of  a  ballot  taken  on 
this  question  clearly  indicate  that  National  Bodies  support  work  on  this  proposed  new  question. 
Therefore,  SC21/WG1  began  work  on  Ql/65  in  June  1993.  [Ref.  SC21  N  7467  1992] 

MiniMAP  is  a  simplified  three-layer  subset  of  the  MAP  specification  intended  for  time- 
critical  applications.  The  World  Federation  of  MAP/TOP  Users'  Groups  has  agreed  to  adopt  the 
Factory  Automation  Interconnection  System  (FAIS)  to  enhance  the  MiniMAP  specification.  The 
addition  was  expected  to  be  part  of  an  update  to  MAP  version  3.0,  known  as  MAP  3.0  (1993)  so 
as  not  to  be  confused  with  the  current  MAP  3.0. 

SC18/WG4  has  proposed  a  new  work  item  for  a  Coordinated  Time  Service  in  an  OSI 
Environment  It  proposes  developing  a  two-part  international  standard  that  would  specify  an 
abstract  service  and  protocol  to  provide  the  date  and  time  of  day  in  response  to  a  request  and 
provide  synchronization  of  time  between  systems.  WD  status  was  expected  in  September  1992, 
CD  in  September  1993,  DIS  in  September  1994,  and  IS  in  September  1993  [Ref.  SC21  N  6749 
1992].  This  work  item  is  relevant  to  the  Time  Management  Function  of  Systems  Management 
(WD  10164-tm,  see  Section  12.1.3.3).  However,  a  WD  is  not  available  now  because  WG4  has 
not  received  substantial  contributions.  Moreover,  the  Australian  NB  wonders  why  this  work 
should  be  progressed  as  a  NWI  by  SC18  when  SC  18  s  "communication"  standards  only  cover  that 
of  Store  and  Forward  -  X.400.  In  their  view,  the  development  of  a  "real  time"  time  management 
system  must  be  the  responsibility  of  SC21.  [Ref.  SC 21  WG4  N  1431  1992] 

SC21/WG4,  in  a  liaison  statement  to  SC18/WG4  regarding  this  topic,  states  that  the 
majority  of  the  requirements  of  the  Coordinated  Time  Services  are  within  the  scope  of  the  Time 
Management  Function  (WD  10164-tm)  (see  Section  12.1.3.3).  [Ref.  SC21  N  7587  1993] 

9.13.2  Transparent  File  Access  (TFA) 

IEEE  P1003.8  is  the  draft  TFA  standard.  TFA  includes  capabilities  for  managing  files  and 
transmitting  data  through  heterogeneous  networks  in  a  manner  that  is  transparent  to  the  user.  IEEE 
P1003.8  completed  its  first  ballot  in  May  1992  and  is  expected  to  become  a  FIPS  by  mid-1993. 
[Ref.  APP 1992]  Chapter  7  discusses  P1003.8  along  with  the  other  POSIX  standards. 

9.13.3  Efficiencies  of  OSI  Protocols 

ITU-TS  SGVn  and  JTC1  (SC6  and  SC21)  are  concerned  with  the  efficiency  of  OSI 
protocols  when  used  over  long  delay  circuits  such  as  satellite  circuits.  SGVH  is  currently 
evaluating  three  proposals  in  terms  of  their  potential  for  efficiency  improvement  as  well  as  in  terms 
of  the  amount  of  changes  they  would  require  on  architecture,  services,  and  protocols  across  all  OSI 
layers: 
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•  Use  of  the  data  link  level  XID  command  (HDLC) 

•  Use  of  extended  fast  select  packets 

•  Use  of  the  proposed  Forward  Acting  Strategy  for  Telecommunications  (FAST). 

SGVn  intends  to  keep  SC21  and  SC6  informed  of  the  progression  of  its  studies.  It  held  a 
special  meeting  on  the  topic  in  October  1992  during  which  approaches  for  a  solution  were 
discussed.  Document  SC21  N  7577  identifies  two  potential  upper  layer  enhancements  to  improve 
die  overall  procedures  for  establishing  communication  between  two  application  entity  instances: 

•  Eliminate  a  protocol  round  trip  when  establishing  an  association 

•  Remove  the  blocking  effect  of  the  A* ASSOCIATE  service. 

The  United  States  suggests  fixed  encoding  as  a  third  area  for  enhancing  the  general,  overall 
efficiency  of  the  upper  layers.  [Ref.  SC21  N  7866  1993] 

In  June  1993,  SC21/WG1  held  a  special  meeting,  with  representatives  from  SG7  of 
ITU-TS,  on  the  subject  of  efficiency  of  OSI  protocols;  the  meeting  was  convened,  in  part,  to 
respond  to  the  liaison  statement  [SC21  N  7577]  from  SG7  in  February  1993.  The  ITU-TS  is 
considering  the  following  approaches  [Ref.  SC21  N  8018]: 

•  Embedding  connection  establishment  protocol  data  units  (PDUs)  at  the  Transport 
Layer.  This  is  currently  not  allowed  because  the  Session  Layer  can  reuse  a  transport 
connection.  Applications  with  well-known  requirements  in  terms  of  initial  application 
PDU  sizes  could  make  use  of  this  approach.  Selecting  such  applications  and 
establishing  a  special  mechanism  for  them  would  be  similar  to  establishing  an 
application-specific  profile.  Care  needs  to  be  taken  to  balance  such  an  approach  with 
other  mechanisms.  For  example,  creating  large  PDUs  to  avoid  segmentation  may 
introduce  unacceptable  delays  if  a  relay  operates  in  the  path. 

•  FAST  method.  This  proposal  involves  the  architectural  implications  of  expressing  the 
concept  of  phases  in  the  operation  of  a  connection  in  the  OSI  Reference  Model  and 
whether  the  FAST  concept  violates  this  expression.  If  so,  modifications  to  the  OSI 
Reference  Model  would  need  to  be  studied. 

SC6/WG4  has  begun  work  on  Enhanced  Communications  Functions  and  Facilities  (ECFF) 
for  die  Lower  Layers  ( Layers  1-4).  In  addition,  SC21/WG1  is  looking  at  a  Fast  Connection  Setup 
(PCS)  feature,  which  is  apparently  consistent  with  the  OSI  Reference  Model  but  would  require 
some  changes  to  service  definitions  (e.g.,  Transport  Service).  An  approach  to  defining  such  a 
feature  has  been  proposed  in  SG6/WG4  (reducing  the  number  of  handshakes  required  to  set  up  a 
connection).  Other  approaches  being  discussed  are  termed  FAST  BYTE,  HDLC  XID  (adds  an 
I-field),  and  extended  HDLC  SABM  (adds  an  information  field).  Some  prefer  the  XID  approach 
(Option  1  in  HDLC)  (e.g.,  SG8  in  ITU-TS)  and  believe  it  possible  to  specify  that  approach  with 
no  revisions  required  in  the  OSI  Reference  Model.  FAST  BYTE  [defined  in  CCll  l  COM  VH-R- 
63(1992)]  apparently  requires  little  or  no  functionality  at  an  OSI  layer  for  a  given  communication 
and  preserves  OSI  compatibility  and  compliance.  This  potentially  should  end  the  need  for  short 
stacks  of  OSI  applications  and  allow  for  much  greater  compatibility  for  efficient  communications 
among  them,  thus  increasing  the  attractiveness  of  OSI.  SG7  planned  full  discussions  of  these 
proposals  at  the  February  1994  meeting. 

9.13.4  Enhanced  Transfer  Mechanisms 

The  emergence  of  new  high  speed  network  technologies  (e.g.,  for  operation  over  fiber 
optic  transmission  facilities)  and  an  expanded  set  of  supporting  requirements  for  applications  (e.g., 
multicast  operation  and  efficiency)  have  spurred  interest  in  the  development  of  enhanced 
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mechanisms  in  fee  lower  four  layers.  SC6  is  working  on  a  project  aimed  at  satisfying  these  needs. 
It  will  develop  guidelines  for  the  lower  layers  to  support  an  enhanced  transport  mechanism  that  can 
include  [Ref.  SC6  N  6887  1991]: 

•  Very  high  data  throughput  capability  for  operation  over  high  speed  (e.g.,  20  Mbps  to 
10  Gbps)  transmission  facilities 

•  Multicast  operation  to  support  multipeer  applications 

•  Selectable  error  control  procedures 

•  Enhanced  QoS  selection  and  management  (e.g.,  for  latency) 

•  Enhanced  out-of-band  signalling  and  synchronization 

•  Efficient  operation. 

The  work  will  involve  the  identification  of  needed  functions  and  their  partition  into 
functional  layers.  Consideration  is  to  be  given  to  interworking  issues  with  present  OSI  conformant 
systems.  The  guidelines  will  take  the  form  of  a  TR,  entitled  Enhanced  Transport  Mechanism 
Guidelines.  [SC6  N  68871  It  is  in  second  WDTR  [SC 6  N  7788,  December  1992]. 

A  related  NP  also  accepted  by  SC6  is  on  group  NSAP  addressing.  Enhanced  Transport 
Mechanisms  and  Group  NSAP  Addressing  [SC6  N6892].  In  a  liaison  statement  to  SC21,  SC6 
pointed  out  that  at  least  two  of  the  technical  areas  to  be  coveted  by  these  two  new  work  item 
proposals  are  thought  to  be  of  particular  interest  to  SC21  [Ref.  SC21  N  6439  1991]: 

•  QoS  enhancements 

•  Multipeer  data  transmission. 

9.13.S  Multipeer  Data  Transmission 

A  May  1990  Canadian  contribution  to  SC21  identified  the  basic  driving  forces  for  multipeer 
communications  (MFC)  as  the  coordinated  interworking  of  more  than  two  application  processes  in 
a  single  activity  and  use  of  inherently  shared  resources  of  certain  subnetwork  types.  "Group" 
processing  was  identified  as  one  of  the  next  "hot  topics"  for  standardization  and  was  expected  to 
include  such  activities  as  conferencing,  co-authoring,  sensor-based  data  collection,  and  process 
control— all  of  which  involve  MPC.  [Ref.  SC21 N  4681  1990] 

Multipeer  data  transmission  (MPDT)  was  originally  die  subject  of  an  addendum  (PDAD  2) 
to  ISO  7498,  but  the  work  in  SC21  was  suspended  November  1989  [SC21  N  4286],  The  US 
national  body  requested  reactivation  of  the  MPDT  project  at  the  May  1991  meeting  of  WG1; 
however,  the  request  was  rejected  pending  technical  contributions.  In  March  1992,  the  US 
national  body  requested  that  SC21  apply  its  procedures  for  the  reactivation  of  MPDT 
[SC21  N  6197]  and  contributed  an  initial  working  draft  text  [SC21  N  6813]  for  an  addendum  to 
ISO  7498-1  for  MPDT.  The  US  concern  was  that  the  MPDT  addendum  should  be  the  architecture 
that  drives  emerging  work  within  the  international  standards  community  on  multicast  and  multipeer 
communication,  including  the  following  [Ref.  SC21  N  6812  1992]: 

•  ITU-TS  X.6  (packet  multicast  service) 

•  ITU-TS  X.gc  (group  communication) 

•  ITU-TS  SGVm  multimedia  (T.mcs) 

•  SC21/SC6,  Enhanced  Communication  Function  in  the  Lower  Layers. 

Also  in  March  1992,  SC6  and  ITU-TS  SGVH  initiated  a  liaison  with  SC21  concerning 
MPDT.  [Ref.  SC21  N  6814  1992]  WG1  replied  to  both  liaisons  and  stated  that  while  it  was 
interested  in  MPDT,  it  currently  lacked  the  resources  to  pursue  it  [Refs.  SC21  N  7062  1992  and 
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SC21  N  7063  1992]  Therefore,  at  its  Plenary  in  Ottawa  in  June  1992,  SC21  resolved  to  accept  the 
WG1  recommendation  not  to  reactivate  the  architectural  work  on  MPDT.  [Ref.  SC21  N  7204 

1992]  However,  at  the  1993  SC21  Plenary,  a  new  work  item  proposal.  Architecture  for  Multipeer 
Communications  [SC21  N  8003],  was  accepted  and  forwarded  to  JTC1.  The  impetus  for  the  new 
effort  was  the  treed  for  multipeer  communications  for  time-critical,  multimedia,  and  ODP 
applications.  As  of  July  1993,  only  the  United  States  and  France  could  commit  resources  to  this 
work.  In  November  1993,  the  JTC1  reported  that  the  new  item  ballot  was  successful,  with  nine 
nations  indicating  a  commitment  to  participate  (the  Netherlands,  Norway,  and  the  United  Kingdom 
declined  to  make  such  a  commitment).  The  new  work  item  plans  a  new  part  (WD  7498-5)  to  the 
OSI  Reference  Model  to  provide  an  architecture  for  the  development  of  OSI  services  and  protocols 
to  handle  multipeer  communications.  CD  is  planned  for  1996,  DIS  in  1997,  and  IS  in  1998.  [Ref. 
SC21  N  8003  1993] 

Among  the  standards  progression  tasks  that  the  newly  formed  OSI  Multipeer/Multicast 
(MPMC)  Consortium  plans  to  undertake  are  the  OSI  Reference  Model  Addendum  (ISO 
7498/PDAD  2)  and  the  ANSI/ITU-TS  SGVD  X.PMS  work.  [Ref.  MPMC  1991] 

The  ITU-T'S  SG  VTI  work  on  multicast/multipeer  covers  the  following  aspects  [Ref. 
SC21  N  7577  1993]: 

•  Development  of  protocols  for  the  support  by  Public  Data  Networks  of  the  services 
available  to  customers  specified  in  Recommendation  X.6,  Multicast  Service  Definition 

•  Possible  enhancements  of  die  OSI  Basic  Reference  Model  for  multicast/multipeer 

•  Development  (or  enhancement)  of  OSI  multicast/multipeer  services  and  protocols  for 
various  layers,  including  study  of  how  the  work  on  X.6  relates  to  the  OSI  Network 
Service. 

A  March  1993  liaison  statement  to  SC21  from  SC6/WG4  on  MPDT  [Ref.  SC21  N  76% 

1993]  identifies  a  set  of  unresolved  issues  associated  with  multicast  communication  in  the  lower 
layers.  However,  current  work  on  multicast  extensions  to  the  connectionless  services  and 
protocols  of  the  Transport  and  Network  layers  does  not  depend  on  resolution  of  these  issues,  and 
should  not  be  delayed  pending  their  resolution.  Three  major  unresolved  multicast  architecture 
issues  are: 

•  Semantics  of  groups  and  group  membership 

•  Specification  of  the  phases  of  operation  for  multicast  communication 

•  Way  in  which  information  about  multicast  conversations  is  exchanged  ("data  flows"). 
In  addition,  the  liaison  statement  identifies  the  following  unresolved  issues  that  are  specific  to  the 
transport  layer:  semantics  of  join,  semantics  of  multicast  data  transfer,  reliability,  sequencing, 
semantics  of  multiple  leaves  and  joins,  and  scope  of  multicast  transport 

Multipeer  data  transmission  has  been  identified  as  essential  to  time  critical  communications 
(see  Section  9.13.6).  ISCVTC184  SC5/WG2  identified  this  need  in  TR  12178,  User  Requirements 
for  Time  Critical  Communications,  and  in  a  December  1993  liaison  statement  to  SC21 
[SC21  N  8384].  Reliance  only  on  peer-to-peer  communications  is  seen  as  too  limiting  for  the 
following  reasons:  temporal  consistency  of  replies  to  requests  from  two  peer  entities  for  the  same 
service  at  the  same  time,  and  spatial  coherence  for  a  request  from  a  peer  entity  for  several  entities  to 
provide  simultaneously  a  service  or  services.  SC5/WG2  has  developed  a  multi-peer  model. 
Produce,  Distributor,  and  Multi-Consumer  Model,  to  ensure  data  can  be  distributed  to  a  number  of 
peer  entities.  [Ref.  SC21  N  8384  1993] 
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At  its  June/July  1993  meeting.  Study  Group  7  of  ITU-TS  reaffirmed  its  intention  to 
develop  an  architecture  for  OSI  multicast  data  transfer,  covering  all  seven  of  the  OSI  layers,  which 
will  be  compatible  with  ITU-TS  X.6  and  with  other  ongoing  work  within  the  ITU-T  concerning 
efficiency  of  OSI  protocols,  multicast,  and  multimedia  communications.  Because  of  its 
commercial  importance,  multicast  data  transfer  will  be  progressed  in  SG7  with  high  priority.  SG7 
has  offered  a  joint  editor  if  SC21  responds  favorably  to  the  October  1993  ITU-TS  invitation  to 
jointly  produce  a  common  test  format  for  this  architectural  enhancement  to  the  OSI  Reference 
Model  [Ref.  SC21  N  8267  1993] 

9.13.6  Time  Critical  Communications  (TCC) 

As  noted  in  Section  9.13.S,  TC184  SC5/WG2  is  developing  standards  for  time  critical 
communications  (TCC).  A  liaison  statement  from  SC21  [SC21  N  7063]  in  May  1992  proposed  a 
partition  of  elements  of  work  among  various  groups,  with  SC21  acting  as  the  bridge  for  groups  in 
JTC1  working  on  time  critical  communications.  In  order  to  gain  formal  approval  to  begin  work  on 
architecture,  SC21/WG1  circulated  Question  1/63  within  SC21,  which  was  approved  in  May  1992 
at  the  SC 21  plenary.  SC21/WG1  is  working  on  the  Time  Critical  Communications  Architecture 
(TCCA). 

In  December  1993,  TCI 84  SC5  forwarded  the  IS  text  of  TR  12178,  User  Requirements 
for  Systems  Supporting  Time-Critical  Communications,  to  ISO  for  publication.  TR  12178 
addresses  the  need  for  performance  and  resilience  for  time  critical  communications,  especially 
when  time-critical  and  non-time-critical  traffic  coexist,  and  specifies  requirements  for  a  TCCA. 
The  focus  is  identification  of  communications  needs  of  tightly  coupled  control  systems.  The  work 
is  intended  to  complement  efforts  focused  on  factory  information  networks  [e.g..  Manufacturing 
Automation  Protocol  (MAP);  see  Section  9.1 1.3.1],  which  are  characterized  by  high  throughput, 
large  packet  service  between  information  process  and  control  processors.  The  effort  is  also 
intended  to  identify  sensor  networks  (e.g.,  fieldbus)  that  concentrate  on  providing  low  complexity 
interface  to  simple  factory  floor  sensors,  actuators,  and  other  devices.  [Ref.  SC21  N  8383  1993] 

9.13.7  Minimal  OSI  Upper  Layers  and  Skinny  Stacks5* 

A  full  OSI  stack  provides  most,  possibly  all,  facilities  and  options  in  a  set  of  standards 
(e.g.,  in  the  upper  layers).  A  skinny  (upper  layer)  stack  (sometimes  called  a  thin  stack)  provides 
protocol  facilities  that  exactly  match  the  requirements  of  the  supported  applications,  in  a  fully  OSI 
conformant  way.  A  stack  is  termed  ‘Tat”  if  it  provides  protocol  facilities  that  (far)  exceed  the 
requirements  of  the  supported  applications.  A  short  stack  has  no  upper  layers — the  applications 
are  on  top  of  the  Transport  Layer. 

ISO/IEC  ISP  11183,  Common  Upper  Layer  Requirements,  defines  a  Minimal  OSI 
(mOSI).  which  is  a  subset  of  full  upper  layer  protocols  that  exactly  matches  the  requirements  of  a 
basic  connection-oriented  application  (BCA — which  itself  only  requires  connect/disconnect  and 
send/receivc  services — thereby  providing  skinny  facilities).  BCAs  typically  use  only  3  percent  of 
the  functionality  of  a  full  stack,  but  most  OSI  platform  implementations  are  full  OSI  stacks, 
implying  that  for  most  applications  the  full  implementation  products  are  fat  The  unused  code  can 
be  expensive  in  terms  of  investment,  storage,  and  execution. 


56  This  section  is  based  on  the  November  1993  briefing  to  EWOS:  [EWOS/T A/93/399] . 
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Facilities  of  mOSI  include  a  kernel  functional  unit  at  each  layer  with  optional  functional 
units,  such  as  authentication  and  application  context  name  negotiation  in  the  Application  Layer. 
One  or  more  presentation  contexts  are  provided  in  the  Presentation  Layer,  and  two-way 
simultaneous  functional  unit  and  512-octet  user  data  for  S-CONNECT  in  the  Session  Layer. 

Potential  applications  of  tpOSI  are  in  the  Industry/Govemment  Open  Systems  Specification 
(IGOSS)  (see  Section  16.1.3.3),  X/Open’s  XTI,  thinOSI,  being  addressed  by  the  IETF  for 
Internet,  and  thinOSI  prototypes,  such  as  one  developed  at  the  University  of  Florida.  Evaluations 
of  performance  are  ongoing. 

9.13.8  TCP/IP-OSI  Convergence  and  Coexistence57 

As  noted  in  Sections  9.7.4  on  Internet  Standards  above,  in  profile  discussions  in 
Chapter  16,  and  in  discussions  of  NATO  and  national  CCIS  initiatives  in  Chapters  18  and  19,  the 
continued  use  of  TCP/IP  in  conjunction  with  transition  to  OSI  is  a  major  issue  for  the  nations  and 
the  national  bodies  participating  in  international  standardization.  Many  existing  and  emerging 
information  systems,  including  CCISs,  have  both  Internet  and  OSI  standard  services  and 
protocols.  Multinational  recommendations  for  GOSIPs  (e.g.,  IGOSS,  see  Section  16.1.3.3)  do 
this  as  well.  Version  3  of  the  US  Application  Portability  Profile  and  US  GOSIP  await  decisions 
from  policy  makers  and  standards  experts  on  the  convergence  and  coexistence  of  TCP/IP  and  OSI. 
(See  Section  16.1.8.) 

One  initiative  in  this  area  is  establishing  formal  liaison  between  the  Internet  Society 
(ISOCyintemet  Architecture  Board  (LAB)  and  ISO/IEC  JTC1/SC6.  SC6  has  proposed  C-liaison 
status;  the  Internet  Society  requested  A-liaison  status  with  JTC1.  Unofficial  liaison  in  the  form  of 
attendance  at  meetings  has  been  ongoing  for  some  time.  Areas  of  common  interest  are  use  of 
CLNP  to  ameliorate  the  problem  of  inadequate  address  space  for  the  Internet  Protocol  Suite  and 
common  interest  in  ECFF  (see  Section  9.13.3)  to  support  multimedia  and  hypermedia  applications. 

EWOS/TA  held  a  special  meeting  in  October  1993  on  TCP/IP-OSI  convergence,  with  focus 
on  the  future  relationship  between  OSI  and  TCP/IP  and  the  potential  role  of  EWOS  in  the 
emergence  of  this  relationship.  The  key  requirements  of  users  are  for  a  global  lower-layer  service 
with  a  well-defined  API  that  supports  ISDN  and  ATM,  optionally  selectable  according  to  user 
needs,  and  for  a  multiplicity  of  applications  that  fulfill  a  range  of  functional  requirements.  A 
further  requirement  is  for  the  protection  of  existing  investment  OSI  and  TCP  each  represents  a 
solution  for  these  requirements.  Options  for  achieving  a  single  solution  may  rely  on  Government 
edict  (not  wholly  successful),  market  forces  (which  might  lead  to  chaos),  and  active  definition  of 
either  an  entirely  new  solution  or  one  that  permits  the  coexistence  of  both  in  a  way  that  allows  the 
aforementioned  requirements  to  be  fulfilled. 

Limitations  on  the  selection  and  specification  of  a  solution  to  the  convergence  issue  include 
existing  mandates  on  GOSIP,  EEC  and  national  rules  on  choices  available  to  public  procurers; 
parallel  use  of  OSI  connection-mode  and  connectionless-mode  services;  and  the  fact  of  ongoing 
development  and  enhancement  of  products  and  protocols  by  both  OSI  and  Internet  communities. 
For  the  long  term,  there  may  be  a  requirement  for  a  new  *1)856”  networking  standard  for  the  lower 
layers.  Possible  short-term  options  are  the  following: 

•  New  relay  and  transport  profiles  for  TCP/IP 

•  Minimal  OSI  (mOSI),  aimed  at  making  OSI  more  competitive 


57  Ibis  section  is  based  on  the  October  1993  EWOS  report  of  a  special  session  of  EWOS/TA  [EWOS/TA/93/391]. 
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•  Application  converters 

•  Lower  layer  profiles  offering  an  API  platform  for  applications. 

The  October  1993  EWOS  meeting  conducted  separate  discussions  on  the  lower  layers  and 
the  upper  layers  concerning  the  requirements  and  needs  for  standardization  for  four  approaches. 
These  approaches  are  defined  as  follows: 

•  Coexistence — several  protocol  architectures  running  on  the  same  physical  network, 
each  providing  different  network  services  and  each  with  its  own  APL  The  networks 
are  essentially  isolated  with  any  bridging  between  applications  on  the  different 
networks  achieved  through  Application  Layer  gateways  rather  than  the 
Network/Transport  Layer. 

•  Interoperability — involves  bridging  or  relaying  at  the  Network  or  Transport  Layer  to 
provide  one,  seamless  network  service  with  a  single  address  space. 

•  Convergence  Protocol  and  API — a  single  protocol  and  a  single  API  at  the 
Network/T ransport  Layer. 

•  Convergence  API  only — a  single  API  at  the  Network/Transport  Layer  with  many 
underlying  protocols.  This  aids  in  portability  of  applications. 

One  outcome  of  the  October  1993  meeting  was  a  new  work  item  proposal  on  ISO/Intemet 
Management  Coexistence  Process.  This  will  focus  on  the  need  for  integrated  management  of  many 
different  components  that  may  be  accessed  by  ISO/ITU-TS  management  and  Internet  management 
Of  particular  interest  is  the  management  of  Internet  SNMP  agents  by  ISO/ITU-TS  CMIP 
managers,  taking  advantage  of  the  numerous  SNMP  management  information  bases  (MIBs).  The 
technical  report  produced  would  contain  a  description  of  the  coexistence  strategy  based  on  the  use 
of  translated  MIBs  in  either  a  proxy  or  native  implementation.  [Ref.  EWOS/T A/93/355  1993] 

9.14  Assessment  of  Coverage  by  Standards 

Network  services  can  be  provided  for  CCISs  using  OSI  protocols  for  electronic  mail. 
Directory,  file  management,  and  exchange  of  telematic  information  and  documents.  At  the  present 
time,  there  are  not  many  high-level  services  provided  by  the  OSI  stacks,  but  the  communications 
aspects  at  lower  layers  are  mature  for  connection-oriented  services  and  maturing  rapidly  for 
connectionless-mode  services.  Only  proprietary  products  are  now  available  with  ISDN  services 
and  protocols,  and  ISDN  usage  is  not  yet  widespread  in  the  United  States.  IEEE  has  developed  a 
draft  standard  (P1003.8  Draft  6)  for  Transparent  File  Access  (TFA).  TFA-like  features  are 
available  in  several  products,  but  there  is  as  yet  no  common  specification  for  such  file  system 
semantics. 

Analysis  is  now  being  performed  in  TSGCE  SG9  to  identify  additional  features  required 
for  military  application  of  MHS  (see  Section  17.3.4.2).  Analysis  of  the  relationship  of  MHS  to 
ACP  129  and  ASN.l  to  STANAG  5500  and  other  message  standards  is  needed.  NATO  has 
requirements  for  media  independent  data  communications  protocols  (e.g.,  for  Link  1  replacement) 
that  have  not  yet  been  developed;  these  standards  could  be  applicable  to  the  communications 
services,  and  more  work  needs  to  be  done  in  this  area  (see  Section  17.5. 1). 

In  a  comparison  of  the  65  service  elements  of  ACP  127,  an  analysis  [Ref.  USPR  1989]  has 
identified  55  as  common  to  MHS-88.  An  additional  five  service  elements  were  shown  to  be  related 
to,  but  not  the  same  as,  those  in  ACP  127: 

•  Precedence  levels  (MHS-88  provides  an  Importance  Indicator) 

•  Message  identification  (MHS-88  provides  somewhat  different  features) 
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•  Prossgn  C  (MHS-88  has  an  obsoleting  indication) 

•  Bell  signal  (MHS-88  provides  a  stored  message  alert) 

•  Date-time  group  (MHS-88  has  a  submission  time  stamp). 

Five  services  provided  in  ACP 127  arc  not  supported  in  MHS-88:  financial  accountability, 
service  message,  network  continuity  indication,  off-line  accountability,  and  tracer  action. 
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IS.  OPERATING  SYSTEM  SERVICE  STANDARDS 

10.1  Requirements 

Operating  system  services  allow  applications  to  gain 
access  to  system  resources  in  terms  of  task  initiation, 
management,  scheduling,  resource  allocation,  logical  and 
physical  device  access,  interrupt  handling,  communication, 
synchronization,  accounting,  file  management,  and  a  range  of 
utilities  that  assist  efficient  development,  testing,  and  execution 
of  applications  software.  Operating  system  services  address 
kernel  services,  commands  and  utilities,  system  administration 
and  management,  and  security.  An  overview  of  standards  for 
operating  system  interfaces  is  given  in  Table  31. 

10.2  Standards  for  Operating  System  Services 

The  key  enabler  for  standardizing  operating  system  services  is  the  use  of  a  robust  standard 
for  the  operating  system  interfaces.  If  the  interface  standard  is  sufficiently  robust  (providing  a 
wide  range  of  services),  then  adherence  to  the  standard  can  provide  the  needed  functionality 
without  having  to  be  limited  on  choice  of  an  operating  system  and  thereby  an  operating 
environment  Many  implementations  available  today  provide  the  basic  operating  system  interface. 
Use  of  options  for  additional  services  outside  a  standard  interface  could  defeat  die  goal  of  adopting 
a  standard  interface  for  operating  system  services,  namely  ensuring  a  high  degree  of  applications 
portability  while  providing  the  necessary  system  services  for  information  exchange  and 
applications. 

10.2.1  POSIX 

The  Portable  Operating  System  Interface  for  Computer  Environments  (POSIX)  is  an 
interface  standard  for  operating  systems  that  is  designed  to  be  vendor  independent  and  to  promote 
application  portability.  In  ISO  it  is  being  developed  as  ISO  9945. 

Table  31.  Status  Overview  of  Key  Operating  System  interface  Standards 

LOC-  Laval  of  oonaamue 
PAV  -  PHitaintawtataliMty 
CMP-  CamplHwm 
MAT-  Maturity 
STB  -  StaMSty 
DFU  -  Do  taotouaaga 
PRL  -  PraMaRMflMMBom 
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10.2.1.1  POSIX  Development 

Development  of  the  POSIX  standards  is  through  the  Institute  of  Electrical  and  Electronics 
Engineers  (IEEE)  Computer  Society's  Portable  Application  Standards  Committee  (PASC) 
[formerly  the  Technical  Committee  on  Operating  Systems  (TCOS)].  [Ref.  CFS  1993b]  The  PASC 
has  formed  a  large  number  of  working  groups.  These  working  groups  and  the  POSIX  standards 
being  developed  were  identified  by  the  same  label,  namely  P1003  with  an  appropriate  extension. 
However,  this  numbering  system  was  revised  in  September  1993  to  reflect  changes  in 
relationships  among  the  standards.  Of  these,  IEEE  1003.1,  IEEE  1003.2,  IEEE  1003.2a, 
IEEE  2003  (formerly  IEEE  1003.3),  IEEE  1003.1b  (formerly  IEEE  1003.4),  IEEE  1003.5, 
IEEE  1003.9  and  IEEE  1224.2  (formerly  IEEE  1003.17)  have  achieved  standards  status.  The 
scope  and  status  of  the  POSIX  work  in  IEEE  is  provided  in  Table  32. 

POSIX  base  standards  include  IEEE  1003.1,  IEEE  1003.2,  and  IEEE  1387.  The 
following  are  amendments  to  IEEE  1003.1:  IEEE  1003.1c  ( Threads  Extensions ),  IEEE  1003.  le 
(Security  Extensions ),  IEEE  1003.  If  ( Transparent  File  Access ),  IEEE  1003.  lg  ( Protocol 
Independent  Interfaces),  IEEE  1003.15  ( Batch  Extensions).  Current  POSIX  profiling  projects 
include:  IEEE  1003.10  (Supercomputing  Profile),  IEEE  1003.13  (Real-Time  Profiles), 
IEEE  1003.14  (Multi-processor  Profile),  and  IEEE  1003. 18  (Platform  Environment  Profile).  The 
Transaction  Processing  Profile  Working  Group  (IEEE  1003.11)  recently  disbanded  [Ref. 
OSN  1993h],  and  the  project  has  been  withdrawn. 

Table  33  summarizes  the  status  of  POSIX  and  POSIX-related  standards  being  developed 
by  IEEE  (see  Table  32  for  details). 

NIST’s  FIPS  151-1  was  based  on  the  1988  version  of  IEEE  1003.1.  The  revision 
completed  in  1990,  FIPS  151-2,  aligns  it  with  IEEE  1003.1-1990. 

WG15  of  SC22  within  the  JTC1  was  formed  in  September  1987  and  assigned 
responsibility  adopting  IEEE  POSIX  standards  as  international  standards.  The  IEEE  standard 
PI 003.1  was  adopted  as  ISO  9945-1  in  1990.  SC22/WG15  eventually  intends  to  remove  the 
focus  on  UNIX  and  the  C  language  to  create  a  generic  interface  specification  between  any  language 
and  a  multiuser  environment  WG15  has  formed  four  rapporteur  (expert)  groups:  Conformance 
Testing,  Internationalization,  Security,  and  Coordination  of  Profile  Activities.  WG15's  division  of 
work  items  is  as  follows: 

•  ISO  9945-1,  System  Interface,  1990 

•  CD  9945-1.1,  Language  Independent  Base  (P1372) 

•  CD  9945-1.2,  Real  Time  and  Extensions  (P1003.  lb) 

•  CD  9945-1.3,  Distribution  Services  (P1003.1f) 

CD  9945-1.3.1,  Transparent  File  Access  (P1003.1f) 

-  CD  9945-1.3.2,  Remote  Procedure  Call  (PI 237) 

CD  9945- 1 .3.3,  Transport  Interface 

CD  9945- 1 .3.4,  Name  Space/Directory  Services  (P1003. 1 g) 

•  DIS  9945-2.1,  Shell  and  Utilities  (P1003.2) 

•  CD  9945-2.2,  User  Portability  Extensions  (PI 003.2a) 

•  CD  9945-3,  System  Management  (P1387) 

•  CD  9945-3.1,  General  Services  (P1387) 

•  CD  9945-3.2,  Batch  Services  (P1003.15). 
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TaM*  32.  POSIX  Standards  Baing  Davalopad  by  the  IEEE  for  Submission  to  ISO 

Through  ANSI 

PIOOa.Q.  POSIX  Guidm  accelerates  consensus  on  Open  Systems  for  Applications  ^ortabiiitv  and  provides 
timely  guidance  to  users  on  how  to  develop  applications  profiles,  it  contains  the  POSIX  Open  System 
Environment  (OSE)  Reference  Model  (Draft  15.  July  1992) 

1003.1.  POSIX— Standard  operating  system  interface  and  environment  to  support  application  portabWty  at  the 
source  code  level.  Approved  (IEEE  Std.  1003.1-1988)  revised  September  1990  (IEEE  Std.  1003.1-1990).  ISO 
9945-1:1990.  FIPS  151-1  was  equivalent  to  IEEE  Std.  1003.1-1988.  FIPS  151-2  is  same  as  1990  version 

P1003.1/US.  see  IEEE  P1372 

Pi 003. la.  System  Interface  Extensions— additional  functions,  preparatory  work  for  Language  Independent 
Specifications.  (Draft  7, 3Q,  1993) 

1003.1b.  Real-Time  Extensions,  approved  October  1993  (formerly  IEEE  PI  003.4) 

Pi 003.1c.  Amendment  to  POSIX.  1 :  Threads  defines  interfaces  for  handing  multiple  threads  of  control  within 
a  single  POSIX  process.  (Draft  8  recirculated  May  1993)  (formerly  IEEE  Pi  003.4a) 

Pi  003-id.  Amendment  to  POSIX.1:  Extensions  to  .4— extend  interfaces  defined  by  POSIX.  1  and  POSIX.4  to 
include  additional  real-time  facilities.  (Draft  4,  September  1992)  (formerly  IEEE  Pi  003.4b) 

Pl00a.le.  Protection,  Audit  and  Control  Interfaces  [C  Language]  (formerly  IEEE  P1003.6.1) 

Pi 003. if.  Transparent  File  Access  (TFA)— develops  system  interfaces  and  other  mechanisms  to  permit 
portability  of  applications  into  environments  where  files,  directories,  etc.,  may  reside  on  remote  systems. 
(Draft  6,  April  1992,  recirculated  November  1992)  (formerly  IEEE  P1003.8) 

Pi  003.1  o.  Protocol  Independent  Interfaces— defines  programmatic  interfaces  that  alow  a  portable  application 
to  communicate  with  another  entity  in  the  network  such  that  the  application  may  be  independent  of  the 
underlying  protocols.  (Draft  1,  September  1992)  (formerly  IEEE  P1003.12) 

1003.2.  Shell  and  Tools — defines  a  standard  source-co de-level  interface  to  shell  sendees  and  common  utility 
programs  for  applications  programs.  (Draft  12  approved  September  1992)  (DIS  9945-2: 1992).  Currently  in 
the  FIPS  adoption  process.  NIST  expected  to  adopt  1003.2  as  a  FIPS  by  December  1993. 

1003.2a.  User  Portability  Extension— provides  extensions...to  support  terminal  users  in  a  consistent  manner 
across  al  conforming  systems.  Approved  as  part  of  1003.2,  September  1992. 

PI  003.2b.  Utilities  Extensions 

Pi 003.2c.  Protection  and  Control  Utilities  (formerly  IEEE  P1003.6.2) 

1003.3.  see  IEEE  2003 
1003.3.1.  see  IEEE  2003.1 
PI  003.3 .2.  see  IEEE  2003.2 

Pi 003.4.  see  IEEE  1003.1b 
Pi 003.4a.  see  IEEE  P1003.1C 
Pi 003.4b.  see  IEEE  Pl000.1d 

1003.5.  POSIX  Ada  BinrSng— determines  the  Ada  environment  interface  and  Ada  extensions  required  for  POSIX; 
provides  a  specification  for  the  Ada  environment  interfaces  and  Ada  required  extensions  so  that  applications 
programs  can  be  written  to  operate  consistently  on  all  conforming  POSIX/  Ada  environments.  (Approved  June 
1992)  A  PAR  for  a  revision  to  this  standard  was  approved  October  1993.  The  new  title  wfll  be  POSIX  Ada 
Language  Interfaces  -  Part  1:  Binding  for  System  Application  Program  Interface  (API). 

P1003.Sb.  Ads  Language  (Real  Time)  Bindings — develop  an  Ada  language  binding  to  the  real  time  POSIX 
standards.  Expected  to  start  balloting  December  1993  (formerly  IEEE  Pi 003.20) 

Pi  003.6.  see  IEEE  P1003.1e  and  see  IEEE  Pi 003 .2c 
PI  003.6.1.  see  IEEE  P1003.1e 
PI  003.6.2.  see  IEEE  P 1003.2c 
PI 003.7.  see  IEEE  PI  387 
PI 003.7.1.  see  IEEE  P1387.4 
PI 003.7.2.  see  IEEE  P1387.2 
PI  003.7.3.  see  IEEE  P1387.3 
PI  003.8.  see  IEEE  P  1003.11 

1003.9.  POSIX  FORTRAN  77  Binding — defines  a  FORTRAN-1977  language  binding  to  applicable  POSIX 
interfaces  and  functionally  as  specified  in  Pi 003. 1,2,4,  etc.,  and  establishes  an  interface  for  FORTRAN  to 
POSIX  such  that  FORTRAN  applications  using  POSIX  functionality  wll  be  portable  at  the  source  code  level 
(Draft  1 1  approved  June  1992) 

P1003.10.  Supercomputing  Application  Environment  Profile  (AEP) — develops  an  AEP  for  supercomputing 
environments.  (Draft  11,  September  1992) 
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Table  32.  (Cont'd) 

P1003-13-  Transaction  Processing  AEP — davatop*  a  Standard  profit  (or  transaction  processing  application 
environments.  (Draft  7,  July  1992)  Working  Group  recently  dubandod.  WITHDRAWN 

PI 003-12.  see  IEEE  Pl003.1g 

Pi 003- 13.  RyaPTIme  AEP  defines  an  AEP  for  real-time  applications  using  the  POSIX  interfaces;  addresses 
three  profMes:  fuMunction  real-time  system,  embedded  control  system,  and  intermediate  real-time  system. 
(Draft  5,  May  1*2) 

Pi 003. 14.  Multiprocessing  AEP— defines  an  AEP  for  multiprocessing  applications  environments  based  on 
relevant  POSIX  standards.  (Draft  7,  April  1982) 

Pi 003.  IS.  Amendment  to  POSIX.  1:  Batch  Environment  Amendment*— define  utilities,  Hbrary  routines,  system 
administration  interfaces,  and  a  host-to-hoat  protocol  to  provide  a  network  queueing  and  batch  system  in  a 
POSIX  environment  (Draft  12,  December  1992) 

PI 003.10.  C  Binding  lor  POSIX  1— defines  a  C-ianguage  binding  between  ISQ/IEC  9945.1:199*  and  the  C 
standard.  (Dnft  12,  December  1992)  [PAR  WITHDRAWN  OCTOBER  1993] 

Pi 003. 10a.  Amendment  f;  System  API  Extensions  [PAR  approved,  March  19,  1992]  [PAR  WITHDRAWN 
OCTOBER  1993] 

1QS3.1Z.  see  IEEE  1224.2 

Pi 003.1 8.  POSIX  Platform  ProNe— establish  a  Platform  Environment  Profile  based  on  the  ISO  9945  work  and 
related  standards  that  describes  a  simple  foundation  for  an  interactive,  multiuser  application  platform.  (IEEE 
standard  is  under  balloting) 

PI 003.1 9.  FORTRAN  90  Language  Bindings — develop  FORTRAN  90  language  binding  to  the  Language 
Independent  Specification  of  the  POSIX  system  application  program  interface  upon  approval  of  the  project  by 
the  IEEE  Standards  Board.  Initiated  July  1992.  [PAR  WITHDRAWN  OCTOBER  1993] 

Pi 003.20 ,  see  IEEE  Pl003.5b 

Pi 003-21-  Reel-Time  Distributed  Systems  Communication  (RTDSC)  —develop  an  application  interface  standard 
that  meets  the  needs  of  the  distributed  real-time  mission-critical  computing  domain.  Expected  to  start  IEEE 
balodng  in  July  1995. 

P10Q3-22-  Guide  to  the  POSIX  Open  Systems  Environment  -  A  Security  Framework 

1224.2.  Directory  Services  API— defines  an  application  programming  interface  to  a  directory  service,  X.500 
functionality.  Approved  March  1993  (formerly  IEEE  Pi 003.1 7) 

P1372.  Language  Independent  SpedUcations  (LIS)— to  provide  a  computer  language  independent  specification 
that  correaponda  exactly  with  IEEE  Std.  1003.1-1990.  (Draft  16,  2Q  1993)  Target  completion  4Q1993 
(formerly  IEEE  Pi 003.1 /LIS) 

Pi 337.  Administered  Systems  (name  changed  from  System  Administration  Interface)— defines  a  standard 
interface  to  utiity  programs  for  administering  systems  that  conform  to  POSIX  Work  is  being  'sliced*  into 
baloteble  partitions,  (formerly  IEEE  PI 003.7) 

Pi 337 2.  Software,  (Draft  8,  March  1993)  (formerly  IEEE  Pi 003.7.2) 

Pi 387.3.  User  Administration,  (PAR  approved  October  1993)  (formerly  IEEE  PI 003.7.3) 

Pi 387.4.  Printing,  (Draft  7,  June  1993)  (formerly  IEEE  P1003.7.1) 

P2003.  Test  Methods:  General— defines  general  requirements  and  test  methods  for  test  suites  to  measure 
conformance  of  an  implementation  to  IEEE  POSIX  and  related  standards.  Approved  March  1991  (IEEE  Std. 
1003.3-1991)  ISO  CO  ballot  initiation  (formerly  IEEE  Pi  003.3) 

P2003.1.  Test  Methods  for  POSIX.  1— defines  test  methods  and  test  assertions  for  POSIX  Approved 
December  1992.  ISO  NP  balot  closed  January  1993  (tormeriy  IEEE  P1003.3.1) 

P2003-2.  Test  Methods  for  POSIX2— defines  test  methods  and  requirements  for  implementations  of  test 
suites  to  measure  conformance  to  POSIX2.  (Draft  8,  July  1 992)  (formerly  IEEE  P1003.3.2) 

Source:  'Applications  Portability  and  Open  Systems  Environments:  Status  Report,*  Roger  J.  Martin, 
NIST,  presented  at  tbe  11th  APP/OSE  Workshop,  NIST,  Gaithersburg,  Maryland,  May  1993.  Updated 
periodically  from  IEEE  Standards  Bearer  and  Open  Systems  Standards  Trucking  Report 


Part  3,  Test  Methods  (General),  was  approved  as  IEEE  standard  1003.3-1991  on 
March  1991,  but  is  now  redesignated  as  IEEE  2003.  IEEE  P1003.3.1,  Test  Methods  for 
POSIX.  1  was  approved  December  1992  and  has  been  redesignated  IEEE  2003.1.  Part  5,  Ada 
Bindings  was  approved  June  1992.  Part  9,  FORTRAN  77  Bindings  was  approved  as  an  IEEE 
Standard  in  July  1992. 
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Table  S3.  Status  of  POSIX  Standards 
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Draft 

Late  1994 
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POSIX  Sy*t*m  Interfaces 

izzzzwm 
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01003.1*  ™ 

POSIX  System  Interface  Extensions 
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1994 

P1003.1b 

Draft 

1994 
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Draft 
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|  P1003.1d 

Extensions  to  Pl003.1b  (US) 

Draft 

TBD 

1:11  IliH 

Security  Interface 

Draft 

1994 
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ii,1  l.H.M,1  I  III  — 

Draft 

1994 

Protocol  Independent  Interfaces 
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1994 

1003.2 

She!  and  Utilities 

Approved 
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User  Portability  Extensions 

Approved 
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Draft 
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Approved 
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1003.5 

June  1992 

Draft 
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1003.9 

Approved 
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01003.10 

Draft 

1994 
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Transaction  Processing  AEP 

Draft 

Withdrawn 

P1003.13 
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Draft 
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Mult  processing  AEP 
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Draft 
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Draft 
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Draft 
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Draft 
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Draft 
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Draft 

1994 
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March  1993 
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Directory  Services/Name  Space 

Approved 

March  1993 

01238 

Draft 

1994 

01238.1  “""T 

BSla  f.' '  r.'  i 

Draft 

1994 

PI  372 

language  Independent  Spec.  (US) 

Draft 

THT” 

"01387 

Administration 

Draft 

ifaivi 

2003 

General  Test  Methods 

March  1991 

Test  Methods  for  POSIX1 

Approved 

December  1992 

12003.2 

1  II  1  i^— 

Draft 

1994  ; 

Source:  Technical  Reference  Model  for  Information  Management,  Version  2.0,  Coordination  Draft, 
Center  for  Information  Management,  DISA,  22  June  1993;  Open  Systems  Standards  Tracking 
Report,  Volume  3,  Number  1,  January  1994,  p.  3;  and  [Schoka  1994]. 


POSIX  is  intended  to  be  compatible  with  both  Database  Language  SQL  and  IRDS  database 
management  languages,  as  well  as  with  OSI  data  communications  and  interprocess 
communications. 

IEEE  POSIX  Security  Working  Group  (formerly  P1003.6)  is  defining  security  extensions 
to  the  base  POSIX  interface  standard  (ISO  9945-1),  to  include  support  for  audit,  privilege, 
discretionary  and  mandatory  access  control,  and  information  labels.  These  have  been  redesignated 
IEEE  P1003.1e  and  IEEE  P1003.2c. 
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IEEE  P1372,  POSIX,  Part  1:  System  Application  Program  Interface  (API)  [Language 
Independent]  is  a  new  POSIX  effort  It  was  formerly  designated  IEEE  P1003. 1/Language 
Independent  Specification  (LIS). 

The  System  Management  FIPS,  the  GOSIP  Network  Management  (GNMP;  FIPS  179) 
was  issued  14  December  1992.  Planned  FIPS  based  on  the  POSIX  standards  include  a 
Transparent  File  Access  (TFA)  FIPS  based  on  PI 003.  If  and  a  System  Management  FIPS  based 
on  P1387.  Plans  were  to  make  the  initial  FIPS  proposal  for  the  Transparent  File  Access  FIPS  in 
early  1993  with  the  expectation  that  a  FIPS  would  be  approved  by  early  1994. 

10.2.1.2  POSIX  Conformance  Testing 

IEEE  Std.  2003.1-1992,  IEEE  Standard  for  Information  Technology — Test  Methods  for 
Measuring  Conformance  to  POSIX  -  Part  I:  System  Interfaces ,  defines  conformance  test  methods 
for  the  POSIX.  1  standard,  based  on  the  methodologies  outlined  in  IEEE  1003.3. 

The  NIST  Computer  Systems  Laboratory  (NCSL)  has  developed  a  POSIX  Conformance 
Test  Suite  (PCTS)  based  on  IEEE  1003.1-1988  (FIPS  151-1).  The  suite  was  in  beta  testing  for 
over  a  year  and  is  available  from  the  National  Technical  Information  Service  (NITS).  The  NIST 
National  Voluntary  Laboratory  Accreditation  Program  (NVLAP)  will  accredit  testing  laboratories 
that  will  be  referred  to  as  Accredited  POSIX  Testing  Laboratories  (APTLs).  On  May  1991, 
NVLAP  announced  the  initial  group  of  seven  labs.  The  policy  document  for  POSIX  Conformance 
Testing  is  NVLAP  Program  Handbook  Computer  Applications  Testing  -  POSIX  Conformance 
Testing.  Testing  is  done  through  agreement  between  the  testing  lab  and  the  client,  without 
NIST/CSL  involvement  However,  NIST/CSL  issues  the  certificate  of  validation.  [Ref.  Hall 
1991] 

An  updated  FIPS  (FIPS  151-2)  points  to  the  1990  version  of  the  base  standard  (IEEE 
1003.1-1990),  and  updates  certain  limits  based  on  experience.  A  new  test  suite  is  being  provided 
that  very  closely  matches  the  methods  described  in  IEEE  2003.1-1992.  [Ref.  OSN  1993h] 

The  Conformance  Testing  Service  has  established  a  CTS-2  POSIX  Project  with  the  goal  of 
a  harmonized  European  and  internationally  recognized  conformance  testing  service  for  POSIX. 
Participants  in  the  project  include  the  National  Computing  Centre  Ltd  (UK),  the  Computer 
Resources  International  A/S  (Denmark),  X/Open  Company  Ltd  (UK),  and  British 
Telecommunications  (UK).  The  project  will  be  establishing  test  laboratories  throughout  Europe 
and  seeking  cross  recognition  with  NIST.  [Ref.  Pink  1991] 

10.2.2  Consortia  Recommendations 

Standards  activities  in  areas  related  to  the  operating  systems  have  been  primarily  in  the  area 
of  developing  international,  nonproprietary  standards  for  interfaces  to  operating  systems.  It 
appears  unlikely  that  an  international  standard  for  an  operating  system  will  be  developed,  in  part 
because  operating  systems  are  closely  tied  to  the  hardware  architecture  of  vendor  products. 

As  indicated  earlier,  POSIX  is  becoming  a  widely  accepted  approach  to  standardizing 
interfaces  to  operating  systems;  the  initial  standard  for  POSIX  (ISO  9945-1)  has  been  completed. 
Consortia  have  been  formed  to  develop  and  promote  profiles  of  standards  that  could  be  the  basis 
for  open  environments  and  portable  systems  within  these  environments.  All  the  consortia  have 
adopted  POSIX;  however,  there  are  differences  in  the  approaches  being  taken.  Activities  of  these 
consortia  in  the  POSIX  area  are  discussed  in  this  section;  additional  information  on  portability 
profiles  is  provided  in  Chapter  15. 
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X/Open.  The  international  nonprofit  consortium  X/Open  developed  extensions  to  UNIX 
System  V  Interface  Definition  (SVID),  which  define  a  distributed  (two-phase)  transaction 
processing  environment  that  meets  OSI  standards.  A  layered  functional  model  for  this 
environment  that  consists  of  resource,  commit,  and  transaction  management  has  been  proposed. 
This  model  requires  certain  extensions  to  the  UNIX  kernel  (guaranteed  output  to  files  and 
cone '.rrent  input  from  peripherals).  The  X/Open  System  V  Specification  (XVS)  is  the  initial 
recommended  standard  for  the  operating  system.  The  extensions  would  be  part  of  a  Common 
Applications  Environment  (CAE),  a  concept  to  promote  software  portability.  This  would  be 
achieved  by  adopting  and  adapting  existing  industry  and  de  facto  standards,  rather  than  by  creating 
a  new  standard.  Future  goals  for  the  CAE  are  alignment58  with  POSIX  P1003.1  (with  a  large 
number  of  extensions)  and  ANSI  X3J1 1  C  together  with  interfaces  for  Indexed  Sequential  Access 
Method  (ISAM)  and  an  embedded  standard  relational  database  language  (SQL).  The  X/Open 
version  of  ISAM  is  based  on  a  major  (implementation  nonspecific)  subset  of  C-ISAM  Version 
2.10  (January  1985)  from  the  Informix  Corporation.  The  initial  X/Open  version  of  SQL  is  not 
fully  compliant  with  ANSI  X3. 135-1986  (Ref.  X/Open  1987;  X/Open  1988;  Lambert  1987]. 
Standards  recommended  for  the  CAE  are  discussed  in  Section  15.1.3.4.  X/Open  now  has  an 
agreement  to  acquire  the  UNIX  trademark  (see  Section  10.2.3). 

OSF.  Another  approach  to  developing  standard  interfaces  to  UNIX-type  systems  is  being 
taken  by  the  OSF,  an  international  consortium  formed  in  May  1988.  OSFs  operating  system, 
OSF/1  was  initially  based  on  the  IBM  AIX,  a  version  of  USL’s  System  5,  Release  3.2.  Release 
1.0  became  available  for  general  release  in  November  1990,  Release  1.1  in  June  1992,  and  Release 
1.2  in  June  1993.  It  is  XPG4  and  POSIX  1003.2  compliant  General  availability  of  Release  1.3 
is  scheduled  for  second  quarter  1994.  Release  1.2  is  based  on  Mach  2.5.  Release  1.3  will  be 
based  on  Mach  3.0  and  derived  from  the  OSF  Research  Institute's  MK5  operating  system  version. 
As  of  March  1993,  10  companies  had  announced  ports  to  12  machine  architectures.  Sections 
15.1.2.4  and  15.1.3.5  discuss  OSF. 

OSF/1  is  based  on  Version  2.5  of  a  microkernel  operating  system  called  Mach  that  was 
developed  at  Carnegie  Mellon  University  (CMU)  under  the  direction  of  Rick  Rashid  (now  Director 
of  Research  at  Microsoft  Corporation).  The  microkernel  is  used  to  provide  a  virtual  platform  on 
which  an  operating  system  may  be  based.  Services  provided  include  process-to-process 
communication,  threads  of  control,  and  mapping  of  virtual  memory  to  physical  memory. 

The  OSF  Research  Institute  is  working  on  a  new  version  of  the  Mach  kernel  that  is  derived 
from  Version  3.0  of  the  CMU  effort.  The  new  microkernel  adds  support  for  symmetric 
multiprocessing  and  C2-leveI  security.  This  version  will  become  part  of  OSF/1  and  part  of  the 
IBM's  Workplace  OS  that  will  run  on  PowerPC  and  Intel  platforms. 

COSE.  One  of  the  most  interesting  developments  is  the  formation  of  an  alliance  between 
three  UNIX  system  suppliers  (Sun,  HP,  and  IBM)  and  three  software  suppliers  (USL,  SCO,  and 
Univel)  to  support  a  specification  known  as  the  Common  Open  Systems  Environment  (COSE). 
The  COSE  specification  is  designed  to  provide  a  common  desktop  environment  for  UNIX, 
together  with  agreed  standards  for  networking  and  management  [Ref.  RNLA  1994,  p.  30]  Its 
first  output  is  a  white  paper  on  Open  System  Process  Acceleration  (June  1993).  The  white  paper 
states  that  the  intent  of  COSE  is  to  accelerate  the  process  by  which  open  system  software 


58  The  October  1992  version  (XPG4)  of  the  X/Open  Portability  Guide  is  aligned  with  POSIX. 
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specifications  are  defined  and  submitted  to  recognized  industry  standards  forums.  [Ref.  OSN 
1993n] 

10.2.3  Operating  System  Standards 

OSCRL.  In  the  1980s,  SC21/WG8  began  work  in  the  area  of  Operating  Systems 
Command  and  Response  Language  (OSCRL).  A  draft  proposal  for  OSCRL  was  planned  but 
never  promulgated.  The  project  is  currently  inactive. 

UNIX  SVR4.  UNIX  System  V  Release  4  (SVR4)  represents  an  attempt  to  incorporate 
the  best  technology  from  the  most  popular  versions  of  UNIX  (System  V,  SunOS,  and  Xenix), 
offering  extensive  levels  of  compatibility,  portability,  and  interoperability.  New  features  designed 
into  SVR4  include  support  for  the  following:  multiprocessing,  multilevel  security,  greater 
reliability,  enhanced  system  administration,  POSIX  compliance,  improved  scheduling  and  real¬ 
time  processing,  DCE  and  COBRA  support,  multinational  language  support  for  all  major  European 
languages  as  well  as  Japanese,  future  support  for  OSF’s  Distributed  Management  Environment 
(DME),  and  use  of  CHORUS  (Section  5.2.11)  microkernel  technology.  OSF/1  represents  an 
alternative  to  SVR4,  using  a  Mach  kernel  with  UNIX  functionality  that  is  based  on  Berkeley  4.4. 
Features  of  OSF/1  include  the  following:  sophisticated  support  for  threads  and  parallelism  (based 
on  Mach),  FOSIX-compliance,  support  for  multiple  file  systems  [including  Sun’s  Network  Hie 
System  (NSF)],  dynamic  configuration,  shared  libraries,  advanced  security  features  (compliant 
with  C2  rating  in  the  Orange  Book),  and  extensive  internationalization  (locale  databases  in  most 
major  European  languages,  as  well  as  multinational  language  support).  [Ref.  RNLA  1994, 
pp.  43-44] 

Mach.  An  alternative  multi-processor  operating  system  to  UNIX  is  the  Mach  operating 
system  developed  by  the  Carnegie  Mellon  University  with  DoD  funding  and  designed  to  control 
one  to  tens  of  processors.  Mach  is  compatible  with  the  Berkeley  variant  of  UNIX  and  has  been 
ported  to  a  number  of  platforms.  Although  Mach  is  not  a  commercial  product,  it  conforms  to  the 
IEEE  POSIX  standard  and  forms  the  core  part  of  OSF’s  OSF/1  operating  system.  [Ref. 
RNLA  1994,  p.  31] 

UNIX  International.  UNIX  International  (UI)  (formerly  Archer,  with  a  membership  of 
42  corporations  and  user  groups)  promotes  UNIX  System  V,  formerly  a  proprietary  standard  of 
AT&T.  Release  4.2  of  UNIX  System  V  is  now  available. 

During  1991,  the  UI  membership  requested  that  UI  expand  its  scope  and  begin  addressing 
a  complete  systems  software  environment  for  open  systems.  As  a  result,  UI  has  defined  UI- 
ATLAS  (see  Section  15.1.3.9).  The  1993  UI  Roadmap  calls  for  the  delivery  of  20  new 
technology  components  and  defines  requirements  for  improved  interoperability  with  existing 
systems  and  enhanced  support  for  multimedia  standards  in  future  UNIX  System  versions. 
Technology  candidates  include:  object-oriented  management,  Windows  emulation,  and  federated 
naming.  UI  has  widened  the  development  process  to  take  input  from  suppliers  outside  of  UNIX 
Systems  Laboratories  (USL),  setting  up  a  process  similar  to  OSFs  requests  for  technology 
(RFTs).  SunSoft's  ONC+  is  the  first  non-USL  Reference  technology.  X/Open's  role  in 
managing  the  common  UNIX  API  (see  Section  15.1.3.4)  will  take  over  a  large  part  of  UI's  role  in 
creating  a  roadmap  for  UNIX,  although  UI's  roadmap  extends  beyond  the  operating  system, 
including  distributed  computing  and  management  [Ref.  OSN  1993q] 

In  June  1993,  UI  issued  its  first  RFTs  for  technology  that  will  enable  users  to  link  objects 
between  documents  created  by  different  UNIX  applications.  The  technology  will  allow  users  to 
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incorporate  data  such  as  graphics,  created  in  one  software  package,  into  a  separate  application,  into 
a  separate  application,  on  the  same  desktop,  or  across  a  network.  It  must  be  compatible  with  and 
complementary  to  the  COSE  environment  and  must  comply  with  OMG's  CORBA.  UI  expects  that 
the  technology  will  be  widely  deployed  in  the  first  half  of  1994.  [Ref.  OSN  1993i] 

In  December  1992,  Novell  announced  its  purchase  of  UNIX  Systems  Laboratories.  Then, 
in  October  1993,  Novell  and  X/Open  announced  an  agreement  that  would  confer  Novell's  "UNIX" 
trademark  to  X/Open.  The  proposed  agreement  would  allow  X/Open  to  certify  industry-standard 
UNIX  operating  systems  based  on  a  common  set  of  X/Open  application  programming  interfaces 
(APIs)  (see  Section  IS.  1.3.4).  The  unified  UNIX  will  be  built  on  X/Open's  Spec  1170,  a 
common  set  of  1,170  APIs  that  vendors  can  enhance  in  their  own  UNIX  implementations.  The 
UNIX  API  (as  the  1 170  Spec  is  now  called)  will  end  the  necessity  for  suppliers  to  adapt  their  code 
to  different  features  of  various  UNIX  flavors  and  will  cause  the  UNIX  market  to  settle  down  to  a 
small  number  of  implementations,  but  not  to  reduce  to  a  single  version.  The  move  is  expected  to 
give  the  UNIX  world  a  united  front  against  other  32-bit  operating  systems  such  as  Microsoft’s 
Windows  NT  and  IBM's  OS/2.  [Ref.  OSN  1993q;  OSN  1993r]  Novell  will  continue  to  sell  its 
UNIX  System  Group's  System  V  operating  system  source  code,  likely  under  the  name  of  UNIX- 
Ware,  which  is  a  Novell-specific  implementation  of  the  Spec  1170  APIs.  [Ref.  Bozman  1993; 
Maggelet  1994] 

Microsoft  hopes  that  its  NT  operating  system  will  lock  UNIX  out  of  any  majority  share  of 
business  desktops.  [Ref.  OSN  1993]  In  December  1992,  UI  released  an  independent  report  that 
predicts  that  Microsoft  NT  will  become  a  dominant  desktop  operating  system,  but  will  not  displace 
UNIX  from  the  server  market  [Ref.  OSN  1993d]  A  June  1993  article  [Ref.  OSN  19931]  claims 
that  as  Microsoft  announces  and  delivers  its  long-heralded  NT  operating  system,  support  is 
spreading  among  system  vendors.  In  addition  to  Digital  Equipment  that  has  long  supported  it, 
Hewlett  Packard  and  NCR  have  also  moved  to  support  it 

10.2.4  Microkernel  Architectures 

Operating  systems  developers  are  moving,  en  masse,  from  integrated  monolithic 
architectures  to  microkernel  architectures.  The  microkernel  architecture  approach  provides  for  the 
separation  of  operating  system  functions  into  a  core,  which  will  run  in  the  most  privileged  state  of 
the  computer,  and  the  rest,  which  run  as  a  set  of  applications  in  nonprivileged  or  user  space.  The 
two  parts  then  interact  via  a  clearly  defined  set  of  interfaces.  This  results  in  systems  that  are  more 
secure,  more  robust,  and  easier  to  maintain,  extend,  and  scale.  Both  the  next  generation  of  UNIX 
releases  from  USL  due  for  release  in  1994  (based  on  CHORUS  System’s  microkernel  technology) 
and  the  next  OSF  operating  system  (planned  for  release  as  OSF/1.3  MK  in  1994  and  based  on  the 
Mach  3  architecture  from  CMU)  will  have  microkernel  architectures.  [Ref.  RNLA  1994,  p.  31; 
Goulde  1993] 

Microkernel  architectures  use  message-passing  communications  between  the  kernel  and  the 
user-space  servers,  which  can  be  used  in  multiprocessing  architectures,  clustered  configurations, 
and  massively  parallel  architectures.  These  architectures  permit  operating  system  upgrades  without 
having  to  bring  down  an  information  system  during  installation  and  tend  to  recover  faster  than 
monolithic  kernels  because  of  their  reduced  complexity.  [Ref.  Goulde  1993] 
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10.3  Assessment  of  Coverage  by  Standards 

Operating  system  services  include  kernel  operations,  commands  and  utilities,  system 
management,  real-time  extensions,  and  security.  Four  of  these  areas  (management  is  excluded)  are 
addressed  by  POSIX.  The  POSIX  standard  provides  the  broadest  applicable  reference  model  for 
developing  portable  applications  at  the  source  code  level.  Considerable  progress  has  been 
achieved,  and  there  is  still  additional  work  in  process.  [Ref.  OSN  1993h] 

Standardization  of  operating  systems  appears  unlikely.  Further,  there  is  no  need  to  select  a 
standard  operating  system  for  an  automated  information  system,  since  such  a  selection  is  viewed  as 
an  implementation  issue.  When  mature,  adopting  the  POSIX  interface  standard  for  information 
systems  appears  to  be  an  attractive  option,  both  to  achieve  some  of  the  required  system  services 
and  to  promote  applications  portability  during  implementation.  Adoption  of  the  current  POSIX 
standard  would  probably  not  fully  meet  system  service  requirements.  For  example.  POSIX 
addresses  independent  operating  systems  cooperating  in  a  distributed  environment,  not  a  single 
operating  system  running  on  multiple  machines.  It  is  not  specifically  designed  for  distributed 
applications,  and  therefore  may  not  serve  an  information  system's  needs  completely. 

Moreover,  IEEE  1003.1-1988,  System  Application  Program  Interface  (FIPS  151-1  and 
ISO  9945-1)  does  not  include  the  capabilities  for  kernel  security  that  are  typically  provided  in  an 
operating  system  kernel.  Also  required  are  real-time  profiles  (IEEE  P1003.13)  and  testing 
specifications. 

Recent  developments  at  X/Open  concerning  the  UNIX  API  also  bear  watching. 
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11.  SECURITY  SERVICE  STANDARDS59 


This  chapter  summarizes  the  status  of  standards  in 
security.  Appendix  F  identifies  organizations  and  standards 
bodies  that  have  contributed  to  development  of  these  standards. 

11.1  Requirements  for  Security 

Security  services  protect  the  components,  mechanisms, 
and  information  of  the  AIS.  Basic  security  features  include 
authentication,  access  control,  confidentiality,  integrity,  and 
non-repudiation. 

Security  features  are  required  by  both  civil  and  military 
systems  and  are  being  addressed  in  some  areas  by  standards 
bodies.  Specific  military  requirements  for  security  and  the 
TSGCE  recommendations  for  addressing  these  requirements  are 
treated  in  Section  17.3.S. 

11.2  Status  of  Standards  for  Security 

11.2.1  Overview  of  Civil  and  Military 
Security  Standards 

Standards  for  security  are  being  addressed  in  the 
following  (details  are  provided  in  sections  that  follow): 

•  ISO  7498-2,  Security  Architecture,  February  1989. 

•  ISO/IEC  10181,  Security  Frameworks  in  Open 
Systems,  January  1992. 

•  NATO  OSI  Security  Architecture  (NOSA),  March 
1988,  UNCLASSIFIED  (Ref.  NOSA  1988], 
defines  the  security  services,  based  upon 
ISO  7498-2,  required  in  the  NATO  OSI  Reference 
Model;  to  be  issued  for  ratification  in  revised  form 
as  STANAG  4250-2. 
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•  Security  Architecture  for  NATO  Information  Systems  Interconnection  (SANISI), 
Version  2.0,  April  1989,  NATO  CONFIDENTIAL  (Ref.  SANISI  1989],  which 
includes  a  description  of  the  Trusted  Communications  Sublayer  (TCS). 

•  Security  annexes  (Annex  B)  for  NATO  OSI  STANAGs  4250-56  and  4261-66  and 
other  STANAGs  planned  for  Layers  6  and  7  (a  draft  Annex  B  has  been  prepared  for 
STANAG  4253  and  4263). 

•  Generic  Upper  Layer  Security  (GULS)  (DIS  11586)  comprises  security  exchange 
service  element  and  presentation  (SC21  N  6992,  SC21  N  6993,  SC21  N  6994,  and 
SC21  N  6995]. 

•  ITU-TS  X.800  Security  Architecture  for  Open  Systems  Interconnection  for  ITU-TS 
Applications  (a  complete  list  of  X.800- series  standards  is  provided  in  Appendix  E  at 
the  end  of  Section  II). 


59  An  early  (January  1994)  draft  of  this  chapter  was  informally  reviewed  by  Mr.  Hal  Staton,  National  Security 
Agency,  Chair  of  TSGCE  SG9  Ad  Hoc  Working  Group  on  Security. 

Chapter  11  241  Security 

UNCLASSIFIED 


UNCLASSIFIED 


•  Lower  layer  security  protocols,  including  the  Network  Layer  Security  Protocol 
(NLSP,  ISO  11577,  November  1993)  and  the  Transport  Layer  Security  Protocol 
(TLSP,  ISO  10736,  November  1993).  [Ref.  Curcio  1994]  (There  is  a  close 
correspondence  of  services  between  the  NLSP  and  TCS  [Ref.  PC  1989];  future  work 
in  TSGCE  SG9  on  the  TCS  will  be  based  on  the  NLSP  [Ref.  Staton  1994].) 

•  IEEE  P1003.6  and  JTC1  SC22  standards  for  POSIX  security  (see  Section  10.2.1). 

•  ANSI  X3.172A-199x,  Computer  Security  Glossary-Addendum  to  American  National 
Standard  Dictionary  for  Information  Processing  Systems,  is  currently  undergoing 
review 

•  MIL-STD-2045- 18500,  Information  Technology  -  Defense  Standardized  Profiles 
AMHxnfD)  -  Message  Handling  Systems  -  Message  Security  Protocol,  Draft,  1993 
(defines  a  profile  of  standards  to  be  used  by  defense  message  systems  requiring  a 
message  security  protocol)  [Ref.  Curcio  1994]. 

11.2.2  Security  Standards  Work  In  ISO49 

SC21/WG1,  SC21/WG3,  and  SC21/WG6  have  begun  a  number  of  initiatives  to  address 
the  models  and  standards  frameworks  required  to  progress  OSI  security  standards.  These  include 
[SC21N  8380  1993]: 

•  OSI  Security  Architecture  (ISO  7498-2),  February  1989 — defines  the  general  security- 
related  architectural  elements  that  can  be  applied  appropriately  in  the  circumstances  for 
which  protection  of  communications  is  required;  provides  a  general  description  of 
security  services  and  related  mechanisms  (e.g.,  authentication,  access  control,  non¬ 
repudiation,  integrity,  confidentiality);  and  defines  the  positions  within  the  OSI 
Reference  Model  where  die  services  and  mechanisms  may  be  provided. 

•  Guide  to  Open  Systems  Security,  December  1993  [SC21  N  8380],  a  technical  report 
developed  to  (1)  define  the  scopes  of  the  OSI  security  frameworks  and  upper  and 
lower  layer  security  models  and  (2)  provide  an  overview  of  the  security-related  work 
within  SC  21. 

•  Security  Frameworks  in  Open  Systems  (ISO/IEC  10181,  eight  parts) — provides 
comprehensive  and  consistent  descriptions  of  specific  functional  areas  of  security 
(e.g.,  authentication  and  access  control),  addressing  all  aspects  of  these  areas  in 
relation  to  how  they  may  be  applied  in  the  context  of  a  specific  architecture  (see 
Section  11.2.2.1). 

•  Network  Layer  Security  Protocol  (NLSP,  ISO/IEC  11577,  November  1994)  and 
Transport  Layer  Security  Protocol  {TLSP,  ISO/IEC  10736,  November  1994) — define 
security  protocols  for  Layers  3  and  4,  respectively  (see  Section  1 1.2.2.2). 

•  Upper  Layer  Security  Model  (ISO/IEC  10745) — provides  standards  developers  with 
the  architectural  model  for  development  of  application-independent  services  and 
protocols  for  security  in  the  upper  layers  of  OSI  and  the  use  of  these  services  and 
protocols  to  fulfill  the  security  requirements  of  a  wide  variety  of  applications,  so  that 
the  need  for  application-specific  A  'Es  to  contain  internal  security  services  is 
minimized.  The  model  addresses  su}  >ort,  positioning,  and  relationship  of  security 
services  and  mechanisms;  interactions  among  layers  in  providing  and  using  security 
services,  management  of  security;  security  policy;  and  security  state.  It  includes 
handling  of  security  transformation  functions  (e.g.,  encipherment)  and  security  check- 
value  functions  from  the  Application  and  Presentation  Layers.  (See  Section  1 1. 2.2.1.) 


60  Based  on  December  1993  edition  of  the  Guide  to  Open  Systems  Security  [SC21  N  8380]. 
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•  Lower  Layer  Security  Model  (SC21  N  7951) — intended  to  provide  standards 
developers  with  the  necessary  baas  for  the  development  of  security-related  protocol 
and  protocol  elements  appropriate  to  the  lower  layers  of  the  OSI  Reference  Model. 
Development  of  this  model  has  been  deferred  by  SC6  (see  Section  11.2.2.2). 

•  Generic  Upper  Layer  Security  (GULS,  DIS  11586,  six  parts),  which  includes  the 
Security  Exchange  Service  Element  (SESE) — defines  a  set  of  generic  facilities  to  assist 
in  the  provision  of  security  services  in  OSI  applications.  GULS  includes  a  set  of 
notadonal  tools  to  support  the  specification  of  selective  field  protection  requirements  in 
abstract  syntax  specification  and  the  specification  of  security  exchanges  and  security 
transformations;  service  definition,  protocol  specification,  and  PICS  proforma  for 
SESE;  and  specification  and  PICS  proforma  for  a  security  transfer  syntax  (see 
Section  11.2.2.4). 

•  Association  Control  Service  Element  (ACSE)  authentication  service 
(ISO  8649/AM  1)  and  protocol  (ISO  8650/ AM  1) — provides  a  field  that  can  be  used 
to  cany  arbitrary  authentication  information  in  a  request  and  a  confirmation. 

•  Management  Plan  for  OSI  Security  Activities  (SC21  SD-7,  June  1990). 

Other  work  is  progressing  in  SC21  on  security  enhancements  to  presentation  standards,  to 
association  control  standards,  and  (as  necessary)  to  other  standards: 

•  Alignment  of  upper  and  lower  layer  security  protocols  (SC21 N  6996) 

•  ASN.l  encoding  rules  to  provide  upper  layer  security  and  compression 
(SC21  N  6130) 

•  Authentication  and  related  security  services  for  distributed  applications  (SC21 N  6099) 
(see  Section  11.2.2.13) 

•  CMIS  access  control  (ISO  9595/AM  4)  and  CMIP  access  control  (planned  amendment 
to  ISO  9596-1;  see  Section  1 1.2.2.10) 

•  Directory  access  control  (ISO  9594-1/AM  1,  ISO  9594-2/AM  1,  ISO  9594-3/AM  1, 
ISO  9594-4/AM  1,  and  ISO  9594-8/AM  1)  and  Directory  authentication  (ISO  9594-8) 
(see  Section  11.2.2.8) 

•  FT AM  security  services  (work  suspended;  see  Section  1 1.2.2.5) 

•  Generic  Security  ESO-OSI  ( External  Security  Object-Open  Systems  Interconnection) 
Abstract  Interface  Standard  (see  Section  11.2.2.12) 

•  Objects  and  attributes  for  access  control  (ISO/IEC  10164-9;  see  Section  1 1.2.2.10) 

•  Open  Distributed  Processing  (ODP)  security  (see  Section  13.2) 

•  Positioning  of  encipherment  and  decipherment  functions  (Application  Layer  versus 
Presentation  Layer)  (SC21  N  5503) 

•  Presentation  confidentiality  and  integrity  (SC21  N  5059) — being  progressed  as 
amendments  to  ISO  8822  and  ISO  8823 

•  Reference  Model  of  Data  Management  (ISO  10032;  see  Section  1 1.2.2.9) 

•  Remote  Data  Access  (ISO  9579;  see  Section  1 1 .2.2.9) 

•  Security  Alarm  Reporting  Function  (ISO/IEC  10164-7;  see  Section  1 1.2.2.10) 

•  Systems  Management  Overview  (ISO/IEC  10040;  see  Section  1 1.2.2. 10) 

•  TP  security  (work  suspended;  see  Section  1 1. 2.2.6). 

SC17/WG4  is  developing  security  services  for  integrated  circuit  (identification)  cards 
(ISO  7816).  SC18  is  developing  security  features  for  Message  Oriented  Text  Interchange 
(MOTIS,  ISO/IEC  10021);  Distributed  Office  Applications  and  Management  (DOAM, 
ISO/IEC  10031);  Document  Filing  and  Retrieval  (DFR,  ISO/IEC  10166);  and  Document  Printing 
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Application  (DP A,  DIS  10175).  SC22/WG15  is  developing  a  security  interface  for  POSIX 
(SC22/WG15  N  46R1) 

SC27,  Security  Techniques  is  also  working  with  SC21  on  several  projects  [Ref.  SC21  N 
6066 1991): 

•  Data  Encipherment  -  Physical  Layer  Interoperability  Requirements,  February  1988 
(ISO  9160) 

•  Data  Integrity  Mechanisms  Using  a  Cryptographic  Check  Function  Employing  a  Block 
Cypher  Algorithm  (ISCVIEC  9797) 

•  Digital  Signature  Scheme  Giving  Message  Recovery,  1991  (ISO  9796) 

•  Entity  Authentication  Mechanisms  (ISO/IEC  9798) 

•  ISO/IEC  9798-1  (Part  1):  General  Model 

DIS  9798-2  (Part  2):  Entity  Authentication  Mechanisms  Using  Symmetric 
Algorithms  (draft  imposed  standard) 

DIS  9798-3  (Part  3):  Entity  Authentication  Using  a  Public  Key  Algorithm 
WD  9798-4  (Part  4):  Entity  Authentication  Using  Nan-Reversible  Functions 
WD  9798-x  (Part  x):  Entity  Authentication  Using  Zero-Knowledge  Techniques 

•  Guidelines  for  Management  of IT  Security  (PDTR 13335) 

•  Hash  Functions,  1993  (DIS  101 18): 

-  DIS  101 18-1  (Part  1):  General  Model 

-  DIS  10118-2  (Part  2):  Hashing  Operation  Using  Symmetric  Block-Cipher 
Algorithm 

WD  10118-3  (Part  3):  Dedicated  Hash  Functions 

•  WD  101 18-4  (Part  4):  Hash  Functions  Using  Modular  Arithmetic 

•  Key  Management  (CD  1 1770  and  WD  10181-8);  the  parts  of  CD  1 1770  are: 

-  WD  1 1770-1  (Part  1):  Framework,  1993  [SC27  N  685) 

-  CD  11770-2  (Part  2):  Key  Management  Mechanisms  Using  Symmetric 
Techniques,  November  1992  [SC27  N  626] 

•  CD  11770-3  (Part  3):  Key  Management  Mechanisms  Using  Asymmetric 
Techniques,  1993 

•  Modes  of  Operation  for  64-bit  and  n-bit  Cipher  Algorithms  (ISO  8372  and 
ISO/IEC  10116) 

•  Non-repudiation  mechanisms  (SC27  N  209) 

•  Procedures  for  die  Registration  of  Cryptographic  Algorithms,  1991  (ISO  9979) 

•  Security  Information  Objects  ( SIO )  [SC21N686] 

Part  1:  Method  and  Guidelines  for  the  Definition  and  Registration  of  Security 
Information  Objects 

Put  2:  Elements  and  Generic  Security  Information  Object  Class  Specifications 

•  Specific  SIO  Class  Definitions  [SC27  N  429,  April  1992],  working  draft. 

•  Zero  Knowledge  Techniques  [SC27  N  345,  November  1991] — the  means  by  which 
possession  of  information  can  be  verified  without  any  part  of  that  information  being 
revealed,  whether  to  the  verifier  or  to  any  third  party.  (TT>ese  techniques  are  applicable 
to  entity  authentication,  data  authentication,  and  digital  signature.) 

TC68,  Banking  and  Related  Financial  Services,  has  two  subcommittees  working  on 
security  standards.  TC68/SC2,  Operations  and  Procedures,  is  developing  standards  for  message 
authentication  (ISO  8730  and  8731),  key  management  (ISO  88732),  message  encipherment 
(ISO/IEC  10126),  sign-on  authentication  (ISO/IEC  11131),  and  data  security  framework 
(ISO  11166).  TC68/SC6,  Financial  Transaction  Cards,  Related  Media,  and  Operations,  is 
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developing  standards  for  message  authentication  (ISO  9807),  pin  management  (ISO  9564),  key 
management  (ISQflEC  11568),  and  cryptographic  devices  (ISOAEC  13492),  and  integrated  circuit 
cards  (ISO/IEC  10202  and  WD  13182).  Listings  of  the  parts  and  titles  of  these  standards  are 
provided  in  Appendix  D  (Section  LD)  and  Appendix  E 

11.2.2.1  Security  Frameworks 

ISO/IEC  10181,  Security  Frameworks  in  Open  Systems,  defines  the  framework  within 
which  security  services  for  open  systems  are  specified.  These  open  systems  include  database, 
distributed  applications,  ODP,  and  OS I.  The  framework  addresses  data  elements  and  sequences.of 
operations  (but  not  protocol  elements)  that  are  used  to  obtain  security  services.  These  security 
services  may  apply  to  the  communicating  entities  of  systems  as  well  as  to  data  exchanged  between 
systems  and  to  data  managed  by  systems.  The  security  frameworks  are  intended  to  provide 
guidance  to  standards  developers  and  are  not  implemen table  standards  against  which  conformance 
can  be  claimed  [SC21  N  7089].  Note  that  the  security  framework  is  being  developed  by 
SC21/WG1,  with  SC27  developing  Part  8,  Key  Management  Table  34  identifies  the  scope  of 
individual  parts  of  the  framework.  Initiation  of  ITU-TS  approval  for  these  parts  is  expected  in 
November  1994. 

In  a  1992  statement  on  scope  and  usability  of  the  Security  Frameworks  for  Open  Systems, 
SC21/WG1  agreed  on  the  following  points  as  a  basis  for  expediting  the  frameworks  and 
improving  their  usefulness  [Ref.  SC21 N  7089  1992]: 

•  The  concept  of  including  some  "compliance”  wording  with  each  framework  was 
generally  (though  not  unanimously)  agreed  to  be  a  useful  step  in  making  known  the 
objectives  of  die  standard. 

•  Reference  to  specific  styles  of  implementation  should  be  non-nonnative,  illustrative, 
not  definitive,  and  should  be  confined  to  examples  only.  No  attempt  should  be  made 
to  provide  complete  sets  of  possible  implementations. 

The  United  Kingdom  feels  strongly  that  if  the  security  framework  is  to  be  used  by  OSI, 
ODP,  or  database  applications,  some  element  of  standardization  is  necessary  to  determine  the  way 
in  which  each  part  of  the  security  framework  is  to  be  applied,  using  the  concepts  and  terminology 
of  the  relevant  area.  It  sees  the  application  of  the  authentication,  access  control,  and  audit 
frameworks  to  OSI  as  the  most  urgent  requirements.  [Ref.  BSI 1991] 

11.2.2.2  Security  Models  and  Protocols*1 

The  purpose  of  the  security  models  is  to  apply  the  security  concepts  detailed  in  the  Security 
Frameworks  to  specific  areas  of  open  systems  architectures. 

Lower  Layers  Security  Model.  While  an  OSI  Lower  Layer  Security  Model  [SC6  N 
5333]  was  begun,  it  was  decided  at  a  joint  meeting  of  SC6/WG2  and  SC6/WG4  in  October  1990 
not  to  progress  it  The  purpose  of  the  model  was  to  provide  standards  developers  with  the 
necessary  basis  for  the  development  of  security-related  protocol  and  security-related  protocol 
elements  appropriate  to  the  lower  layers  of  the  OSI  Basic  Reference  Model  The  model  would 
address  concepts,  guidelines,  interactions,  and  management  requirements.  Security  in  Lower 
Layer  Protocols  and  Guidelines  [SC6  N  6957]  may  form  the  basis  of  a  future  standard.  A  number 


61  Discussion  for  this  section  was  taken  from  the  January  1991  Guide  to  Open  Systems  Security  [SC21  N  5533] 
and  updated  based  on  the  December  1993  edition  of  this  document  [SC21  N8380]. 
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of  security  issues  need  to  be  resolved  before  this  would  be  likely.  [Ref.  SC6  N  6219  1990; 
Walters  1991] 


Table  34.  OSI  Security  Frameworke— ISO/IEC  10131 


•  Part  1  (to  10181-1.2),  Overview,  June  1993  [S&1  W  7083)— Describes  the  wganEaBon  of  the 
Mcurity  framework,  define*  security  concepts  (e.g.,  domains,  authorities.  policies)  that  are 
required  in  more  then  one  part  of  the  security  framework,  and  describee  the  interrelationship  of  the 
eervicee  and  mechaniems  identified  in  other  parts  of  the  framework.  Initiation  of  ITU-TS  approval 
expected  November  1994. 

•  Past  2  (ISOriEC  10181-2),  Authentication  Framework,  June  1993  [SC21  N  7853}— Authentication  is 
the  process  of  corroborating  an  identity.  The  standard  defines  basic  concepts,  identifies  possible 
classes  of  mechanisms,  defines  services,  identifies  functional  requirements  for  protocols, 
identifies  management  requirements,  and  aligns  terminology  and  concepts  with  ISOAEC  9798, 
Entity  Authentication  Mechanisms.  Two  amendments  are  in  WD  status:  Refinement  of 
Subcomponents  of  Claimant  and  Verifier  and  Classification  for  a  New  Class  of  Mechanisms  to 
Defeat  Opportunistic  Attacks.  A  new  work  item  on  Authentication  Elements,  which  would  be  an 
amendment,  has  been  proposed. 

•  Part  3  (DIS 101 81 -3),  Access  Control  Framework,  September  1 993  [SC21  N  8224}— Access  control 
is  the  process  of  determining  that  uses  of  resources  within  an  open  system  environment  are 
permitted  and.  where  appropriate,  preventing  unauthorized  access.  Accesses  may  be  to  a  system 
or  within  a  system. 

•  Part  4  (DIS  10181-4),  Non-Repudiation  Framework,  December  1993  [SC21  N  8378}— Non- 
repurfiation  is  a  security  service  that  provides  proof  of  origin  or  delivery  of  data  in  order  to  protect 
the  eender  against  the  false  denial  by  the  recipient,  that  the  data  has  been  received,  or  to  protect 
the  recipient  against  false  denial  by  the  sender  that  the  data  has  been  sent.  The  use  of  appropriate 
mechanisms  is  coupled  with  the  necessary  assurance  mechanisms  providing  proof  about  certain 
properties  of  the  communications  between  the  entities  involved,  such  as  its  integrity,  origin,  time, 
and  destination.  Non-rapucSation  implies  the  existence  of  an  agreed  third  party  whose  primary  role 
is  to  arbitrate  disputes  resulting  from  non-repudiation. 

•  Part  5  (DIS  10181-5),  Confidentiality  Framework,  February  1993  [SC21  N  7602]— The  maintenance 
of  the  secrecy  of  data  is  called  confidentiality. 

•  Part  6  (DIS  10181-6),  Integrity  Framework  February  1993  [SC21  N  7603}— The  integrity  framework 
addresses  the  constancy  of  a  data  value  and  not  any  other  form  of  invariant  that  such  a  value  may 
possess.  In  particular,  it  does  not  address  the  constancy  of  any  information  that  the  data  is 
deemed  to  represent.  There  are  two  types  of  integrity  mechanisms  needed  for  two  types  of 
constancy.  The  first  is  die  constancy  of  the  value  of  data  in  an  environment  in  which  a  random 
modification  to  integral  data  may  be  made.  The  second  is  the  constancy  of  the  value  of  data  in  an 
environment  in  which  a  modffication  to  integral  data  may  deSberatMy  be  made  to  defeat  the  integrity 
mechanism. 


Part  7  (CD  10181-7.2).  Security  Audit  Framework  March  1993  [SG21  N  7885}— This  second  CD 
describes  a  model  of.  a  system's  audit  trail,  a  description  of  audit  events  and  the  different  types  of 
information  involved,  and  its  relationship  to  management  activities. 

Part  8  (WD  10181-8),  Key  Management,  November  1991  [SC21  N  6066— Work  on  this  part  is  being 
carried  out  in  SC27.  The  purpose  of  key  management  is  to  provide  procedures  for  handling 
cryptographic  keying  material  to  be  used  in  symmetric  or  asymmetric  cryptographic  mechanisms. 
Key  management  includes:  key  generation,  key  distribution,  key  installation,  key  storage,  key 
archiving,  and  key  deletion.  A  fundamental  problem  is  to  establish  keying  material  whose  origin, 
integrity,  and.  in  the  case  of  secret  keys,  confidentiality  can  be  guaranteed.  The  work  addresses, 
in  part,  the  concern  about  proliferation  of  protocol-specific  key  management  mechaniems. 

Sources:  tS 
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The  issue  of  adding  security  services  to  Layer  2  in  ISO  7498-2  was  raised  by  SC21/WG1 
in  May  1991.  The  IEEE  standard  for  Interoperable  LAN  Security  (802.10  Pan  B)  provides  data 
confidentiality,  connectionless  integrity,  data  login  authentication,  and  access  control  security 
services  at  OSI  Layer  2,  while  ISO  7498-2  provides  only  data  confidentiality.  The  relevant 
document  is,  Data  Link  Layer  Security  [SC6  N  6927;  SC21  N  6346] 

Network  Layer  Security  Protocol  (ISO  11577).  The  NLSP  is  based  on  three 
standards  efforts.  One  pari  of  the  US  Secure  Data  Network  System62  (SDNS)  is  a  connectionless 


62  One  of  tbe  objectives  of  SDNS  is  to  emphasize  commercial  participation  in  developing  security  products. 
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layer  3  security  protocol  (SP3)  equivalent  to  the  end-to-end  encryption  portion  of  die  TCS 
identified  in  draft  STANAG  4250-2  and  described  in  SANISI.  Northern  Telecom's  SPX  security 
protocol  adds  connection -oriented  service  to  SP3.  The  United  Kingdom's  End-to-End  Security 
Protocol  (EESP)  adds  connection-oriented  services  to  SP3  and  includes  integrity  and  traffic 
padding. 

NLSP  can  operate  both  in  the  CO  and  CL  modes  and  can  be  implemented  in  both  end 
systems  and  intermediate  systems.  Both  modes  support  address  (source/destination) 
confidentiality.  The  NLSP  protocols  makes  use  of  the  concept  of  a  security  association  (for 
cryptographic  keys  and  associated  parameters)  and  provides  security  on  die  basis  of  the  quality  of 
service  the  Transport  Layer  demands  and  the  quality  of  service  the  domain  administration 
proposes.  In  October  1993,  the  SC6  plenary  agreed  to  approve  the  NLSP  for  IS  status  [Ref. 
Curcio  1994]. 

Transport  Layer  Security  Protocol  (ISO  10736).  TLSP  is  based  on  the  SDNS 
Layer  4  security  protocol  (SP4)  and  specifies  optional  extensions  to  both  die  connection-oriented 
transport  protocol  (ISO  8073)  and  connectionless-mode  transport  protocol  data  unit  (TPDU) 
transmission  (ISO  8602)  standards  to  permit  use  of  cryptographic  techniques.  Since  die  protocol 
operates  as  an  extension  only,  it  does  not  preclude  unprotected  communication  between  transport 
entities  implementing  ISO  8073  or  ISO  8062.  In  October  1993,  the  SC6  plenary  agreed  to  approve 
the  TLSP,  together  with  Amendment  1,  Exchange  of  Security  Attributes,  for  IS  status  [Ref.  Curcio 
1994]. 

Upper  Layers  Security  Model  (ISO  10745).  The  Upper  Layer  Security  Model 
provides  the  necessary  basis  for  the  development  of  security-related  protocol  elements  for  the 
secure  exchange  of  information  between  open  systems,  with  the  interchange  of  information  related 
to  security  policy  control  and  management,  and  with  services  and  mechanisms  for  controlling 
access  to  resources  accessible  via  OSI.  It  addresses  the  following: 

•  Security  aspects  of  communication  in  the  upper  layers  of  OSI 

•  Relationships  between  security  services  and  mechanisms  in  the  upper  layers,  to  be 
considered  in  greater  detail  than  is  provided  in  ISO  7498-2 

•  Properties  of  the  possible  combinations  of  security  services  and  mechanisms  in  the 
upper  layers 

•  Interactions  among  Application,  Presentation,  and  Session  Layers  in  providing 
security  services 

•  Invocation  of  lower  layer  security  services 

•  Requirements  for  security  management  in  the  upper  layers. 

The  Upper  Layer  Security  Model  (ISO  10745)  recendy  progressed  to  ISO  status.  It 
addresses  primarily  FT AM  security  requirements,  not  those  of  distributed  applications  such  as 
Directory,  TP,  and  X.400.  [Ref.  X3  1991o] 

11.2.2.3  Requirements  and  Approaches  for  Security 

In  March  1990  at  the  Workshop  on  Distributed  Applications  in  Phoenix,  the  following 
observations  on  security  were  made  [Ref.  SC21  N  4526  1990]: 

•  It  is  highly  desirable  to  standardize  a  general  approach  to  providing  security  in  the 
Application  Layer.  This  can  be  accomplished  by  supporting  a  variety  of  security 
methods  that  involve  communication  of  security  information,  such  as  two-way  or 
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three-way  authentication  exchange,  privilege  attribute  certificate  transfer,  and  key 
negotiation  sequence. 

•  A  security  method  would  consist  of  semantics,  syntax,  and  procedural  rales  relating  to 
die  communications  aspects  of  the  method. 

•  There  appear  to  be  three  possible  OSI  architectural  approaches  to  supporting  security 
methods: 

No  generic  security  ASE(s),  in  which  the  syntax  and  procedural  rules  for  any 
security  method  are  imported  into  the  specification  of  an  application-specific  ASE. 
One  generic  ASE,  in  which  one  ASE  is  provided  that  can  import  into  its  abstract 
syntax  die  syntax  of  any  security  method. 

Multiple  purpose-specific  security  ASEs,  in  which  each  ASE  incorporates  the 
procedural  rales  and  syntax  for  a  particular  security  method  or  group  of  closely 
related  methods  (e.g.,  an  ASE  to  support  two-way  authentication  exchanges). 

•  Satisfaction  of  security  requirements  of  TP,  Directory,  and  OSI  Management  will 
depend  on  addressing  security  modelling  issues  related  to  distributed  applications. 

•  Access  control  to  data  resources  must  address  the  data  model  being  used  by  individual 
applications  such  as  DFR,  DTAM,  FT AM,  IRDS,  RDA,  SQL,  etc.  Use  of  a  common 
data  modelling  approach  provides  the  potential  for  use  of  common  access  control 
facilities  to  such  data  resources  and  consequently  increases  the  attractiveness  of  the 
common  data  model  approach  in  order  to  prevent  the  need  for  re-specification  of 
access  control  facilities  for  data  management  applications. 

11.2.2.4  Security  Exchange  and  Generic  Upper  Layer  Security 

SESE.  A  security  exchange  is  the  transfer  of  protocol-control-information,  called  security 
exchange  information,  between  open  systems  as  part  of  the  operation  of  a  security  mechanism.  An 
ASE  that  supports  die  communication  of  security  exchange  information  is  designated  a  Security 
Exchange  Service  Element  (SESE).  SESE  will  provide  for  the  transfer  of  information  between  a 
pair  of  application-entity  invocations  in  support  of  security  services  such  as  authentication,  access 
control,  confidentiality,  and  integrity.  The  security  exchange  would  be  allowed  to  occur  either  in 
conjunction  with  association  establishment  or  at  any  time  on  an  established  association. 
Encryption/signature  functions  could  be  located  in  either  the  Application  Layer  or  the  Presentation 
Layer.  SESE  includes  a  standard  method  for  defining  security  exchange  information  using 
ASN.l[Ref.  SC21  N  5002  1990] 

GULS.  ITU-TS  Q19/7  and  WG6  have  decided  to  progress  the  SESE  and  Presentation 
Layer  security  documents  together  as  a  multi-part  standard  on  Generic  Upper  Layers  Security 
(GULS).  GULS  will  comprise  six  parts: 

•  DIS  1 1586-1  (Part  1):  Security  Exchange  Overview  and  Specification  Framework, 
August  1993  [SC21  N  8182] 

•  DIS  1 1586-2  (Part  2):  Security  Exchange  Service  Element  (SESE)  Service  Definition, 
August  1993  [SC21  N  8183] 

•  DIS  11586-3  (Part  3):  Security  Exchange  Service  Element  (SESE)  Protocol 
Specification,  August  1993  [SC21  N  8184] 

•  DIS  11586-4  (Part  4):  Protecting  Transfer  Syntax  Specification,  August  1993 
[SC21  N  8185] 

•  WD  11586-5  (Part  5):  Security  Exchange  Service  Element  (SESE)  PICS  Proforma, 
June  1993  [SC21N  7912] 

•  WD  11586-1  (Part  6):  Protecting  Transfer  Syntax  PICS  Proforma,  June  1993 
ISC21  N  7913]. 
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11.2.2.5  FTAM  Security 

FTAM  security  services  were  the  subject  of  standardization  work  in  SC21  during  1990  to 
1992,  but  this  work  was  suspended  in  June  1993.  Enhancements  to  FTAM  Security  Services 
[JTC1  N  955]  (the  new  work  item  proposal).  Security  Aspects  of  FTAM  [SC21  N  6811, 
March  1992],  and  ISO  8571-1/WDAM  5,  Enhanced  Security  for  FTAM  [SC21  N  7927, 
May  1993]  were  examples  of  the  work  completed,  generally  based  on  use  of  passwords  and 
access  control  lists.  Suspension  was  due  to  lack  of  resources  and  the  emerging  GULS  standard. 

FT AM-specific  requirements  include  the  need  for  an  overall  security  policy  in  FTAM  so 
that  any  changes  become  part  of  a  coherent  whole.  Possible  extensions  that  could  be  made  to  the 
existing  FTAM  protocol  and  service  include  authentication,  access  control  list,  mandatory  or  label 
based  access  control,  change  attribute,  and  filestore  management 

11.2.2.6  TP  Security 

Transaction  Processing  Security — a  new  work  item  that  was  suspended  in  June  1993 — 
addressed  the  formulation  and  provision  of  mechanisms  to  meet  a  number  of  security  services, 
including  authentication,  access  control,  confidentiality,  integrity,  non-repudiation,  auditing, 
"management"  access  right  revocation,  replay  protection,  prevention  of  the  denial  of  service, 
reliability,  and  traffic  flow  confidentiality.  Suspension  was  due,  in  part,  to  concerns  about 
alignment  of  early  work  with  ISO  7498-2  and  the  emerging  SESE  in  GULS  (DIS  1 1586). 

11.2.2.7  ODA  Security 

Changes  are  being  made  to  ODA,  ISO  8613,  to  improve  the  security  aspects.  ODA 
provides  protection  for  documents  as  a  whole  or  for  parts  of  a  document.  Confidentiality, 
integrity,  authentication,  and  non-repudiation  of  origin  are  all  supported  using  encipherment, 
fingerprints,  and  seals.  [Ref.  SC21  N  4472  1990] 

11.2.2.8  Directory  Security 

ISO  9594-1/AM  1,  ISO  9594-2/AM  1,  ISO  9594-3/AM  1,  and  ISO  9594-4/AM  1  develop 
a  model  for  access  control  and  an  access  control  scheme  for  general  use  (in  Part  2)  and  (in  Parts  3 
and  4)  provides  "hooks"  whereby  the  access  to  directory  information  can  be  controlled.  Hooks 
inserted  by  the  amendments  to  Parts  3  and  4  allow  a  variety  of  external  access  control  schemes  to 
be  used,  in  addition  to  the  basic  access  control  scheme  of  Part  2.  The  Directory  Authentication 
Framework  (ISO  9594-8)  describes  a  security  token  protected  by  integrity  and  data  origin 
authentication  security  services  called  a  certificate.  The  mechanism  used  to  provide  this  protection 
involves  the  use  of  public  key  cryptosystems.  Three  authentication  exchange  mechanisms  are 
defined  to  provide  unilateral  or  mutual  authentication. 

A  new  work  item,  Security  Enhancement  to  Directory  failed  to  qualify  for  acceptance  to  the 
JTC1  work  program,  but  has  been  incorporated  into  another  NWI,  Authentication  and  Related 
Security  Services  for  Distributed  Applications  (see  Section  11.2.2.13).  However,  a  new  work 
item  proposal.  Enhancement  of  Directory  Operational  Security ,  has  met  the  criteria  for  acceptance 
into  the  JTC1  program  of  work,  and  SC21  has  been  requested  to  respond  to  the  comments 
received.  The  June  1993  draft  is  SC21  N  7932.  It  would  result  in  addenda  to  ISO  9594-1  through 
ISO  9594-9  and  possibly  one  new  part  Target  dates  are  as  follows:  WDAM  in  November  1994, 
PD  AM  in  October  1995,  DAM  in  October  1996,  and  AM  in  October  1997.  Section  9.11.7.3 
describes  a  related  new  work  item  proposal  for  Certificate  Definitions  [SC21  N  7102]. 
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11.2.2.9  Database  and  Data  Management  Security 

SQL.  SQL2  specifies  some  security  functionality,  but  the  standard  (ISO  9075)  does  not 
address  how  a  secure  database  should  be  built.  ISO  9075  does  provide  user  authorization 
parameters  for  users  of  SQL  data  and  services. 

Remote  Data  Access  (RDA).  RDA  (ISO  9579-1)  allows  interactive  access  to  a  remote 
database  from  a  terminal  and  carries  the  user  identity  and  authorization  identity  in  the 
request/indication  service  primitives  when  an  RDA  dialogue  is  being  set  up  with  a  remote  node — 
the  dialogue  is  rejected  if  either  the  user  or  authorization  identities  are  found  to  be  invalid.  RDA 
does  not  dictate  the  format  or  meaning  of  this  security-related  information. 

POSIX.  Since  the  security  of  the  operating  system  needs  to  be  considered  in  building  a 
(secure)  database,  POSIX  standards  are  also  relevant  to  the  security  of  databases. 

Reference  Model  of  Data  Management  (RMDM).  ISO/IEC  10032  (RMDM) 
describes  access  control  in  terms  of  privileges,  provides  an  architectural  model  in  which  access 
control  data  are  considered  similar  to  database  data,  and  lists  a  standardized  approach  to  access 
control  as  a  technical  objective  associated  with  data  management  standardization.  Access  control  is 
the  only  security  service  supported  within  the  scope  of  data  management,  although  requirements 
for  other  security  services  are  identified  in  ISO/IEC  10032. 

Information  Resource  Dictionary  System  (IRDS).  An  IRDS  documents  and 
controls  an  enterprise’s  information  resources.  Access  to  an  information  resource  dictionary  is 
required  to  be  limited,  and  the  ISO/IEC  10027  (IRDS  Framework )  characterizes  the  criteria  that 
might  be  used  to  decide  access.  ISO/IEC  10728  (IRDS  Services  Interface)  specifies  mechanisms 
for  interfaces  to  IRDS  services. 

11.2.2.10  Management  Security 

A  brief  amendment  (AM  4)  on  access  control  has  been  added  to  ISO  9595,  Common 
Management  Information  Service  (CMIS)  Definition.  It  specifies  the  presence  and  purpose  of 
access  control  parameters,  but  it  does  not  define  the  nature  or  format  of  the  parameters. 
ISO/IEC  10040  (Systems  Management  Overview)  identifies  security  management  functions  and 
relates  them  to  the  OSI  Reference  Model  and  the  framework  for  audit.  Three  parts  to 
ISO/IEC  10164  (Systems  Management)  specify  security  services  for  OSI  management:  Security 
Alarm  Reporting  Function  (Part  7),  which  can  be  used  by  applications  using  CMIS  to  raise 
security  alarm  events  based  on  the  Alarm  Reporting  Function  (Part  4);  Security  Audit  Trail 
Function  (Part  8),  in  which  event  reports  are  sent  to  an  audit  trail  log;  and  Objects  and  Attributes 
for  Access  Control  (Part  9),  which  models  the  provision  of  access  control  to  management  objects 
at  a  target  end  system. 

11.2.2.11  International  Standardized  Profile  (ISP)  Security 

It  has  been  suggested  that  the  scope  of  TR  10000  be  extended  to  address  the  security 
features  in  ISPs.  An  ISP  may  contain  security  features  if  one  (or  more)  of  the  base  standards  to 
which  it  refers  contain  security  features.  In  general,  the  specification  of  an  ISP  having  security 
features  has  two  distinct  parts,  one  concerned  with  security-related  functions  and  one  concerned 
with  other  functions.  This  specification  is  referred  to  as  a  security  sub-profile.  An  ISP  may 
contain  one  (or  more)  security  sub-profiles.  The  security  sub-profile  comprises  [Ref. 
Humphreys  1991]: 
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•  A  description  of  the  target  system  environment  in  which  the  sub- profile  is  intended  to 
be  used 

•  An  identification  of  the  range  of  (security)  threats  that  the  sub-profile  is  intended  to 
counter  in  the  target  system  environment 

•  A  specification  of  how  security  functions  in  base  standards  should  be  used  to  counter 
the  assumed  threats 

•  A  specification  of  the  security  mechanisms  that  should  be  used  to  provide  the 
necessary  security  functions  (where  the  base  standards  provide  some  freedom  of 
choice) 

•  A  specification  of  the  range  of  the  realizable  quality  attainable  through  the  use  of  this 
sub-profile. 

11.2.2.12  Generic  Security  ESO-OSI  (External  Security  Object-Open 
Systems  Interconnection)  Abstract  Interface  Standard 

The  UK  originally  proposed  this  standard  in  a  work  plan  for  the  security  of  distributed 
applications.  The  strawman  document  [SC21/WG6  N  1158]  defines  an  abstract  interface  between 
two  types  of  specifications  for  ISO  application  security:  (1)  an  OSI  application  protocol 
specification  including  enhancements  for  security  and  (2)  a  specification  for  a  security  support 
function  based  on  a  specific  set  of  mechanisms  (i.e.,  ESO  in  terms  of  the  Upper  Layers  Security 
Model).  It  is  based  on  a  Generic  Security  Service  API  proposed  to  the  Internet  Common 
Authentication  Technology  WG,  although  this  document  does  not  define  itself  as  a  concrete  API. 
[Ref.  SC21  WG6  N  1158  1992] 

11.2.2.13  Additional  Security  Standards  Work  in  ISO 

Conformance  Testing.  The  UK  contributed  a  discussion  paper  on  Conformance 
Testing  for  OSI  Security  to  the  SC21AVG1  meeting  in  Ottawa  in  May  1992.  The  paper  supports 
the  establishment  of  a  new  question  on  Conformance  in  OSI  Security  to  define  the  scope  of  work 
to  be  done  on  this  topic  in  SC21  and  to  get  this  agreed  with  SC27,  to  ensure  proper  coordination  of 
the  SC21  activity  with  related  SC27  work.  [Ref.  SC21  WG1  N  1 140  1992]  A  majority  of  national 
bodies  voting  on  Ql/69,63  Conformance  Assessment  for  OSI  Security,  support  work  on  this 
proposed  new  question.  [Ref.  SC21  N  7473  1992] 

Authentication  and  Related  Security  Services  for  Distributed  Applications. 
In  June  1991,  a  new  project  was  proposed  to  define  an  authentication  service  for  distributed 
applications  in  an  open  systems  environment  [SC21  N  6099].  However,  the  NP  ballot  failed  to 
receive  the  required  level  of  commitment  by  National  Bodies  for  work  to  proceed.  For  the  same 
reason,  a  related  project,  Security  Enhancements  to  the  Directory  Authentication  Framework 
[SC21 N  6172]  also  failed.  The  United  States  therefore  suggested  merging  the  two  efforts  and  an 
NP  to  that  effect  (NW1  on  Authentication  and  Related  Security  Services  for  Distributed 
Applications)  has  met  the  criteria  for  acceptance  into  the  JTC1  Program  of  Work  and  has  been 
assigned  to  SC21/WG8  for  development  [Ref.  SC21  N  7580  1993].  An  early  draft  is 
SC21  N  7914,  Working  Document  on  Authentication  and  Related  Security  Services,  August 
1993.  This  standard  will  define  services  for  distributed  applications  in  an  Open  Systems 
Environment  to  support  authentication,  access  control,  and  key  management  A  five-part 
international  standard  is  being  contemplated  with  target  dates  as  follows:  CD  expected 


63  Questions  are  used  lo  direct  new  wait;  a  list  of  questions  for  SC21  is  provided  in  Section  2  of  Appendix  G. 
Chapter  11  251  Security 

UNCLASSIFIED 


UNCLASSIFIED 


December  1994,  DIS  December  1995,  and  IS  December  1996.  The  parts  are  Model,  Generic 
Abstract  Service,  Security  Application  Service  Definitions,  Protocols,  and  PICS  Proforma. 

The  scope  of  the  standard  for  authentication  and  related  security  services  will  include  a  key 
distribution  protocol  (KDP).  The  NIST  will  support  the  development  of  a  working  draft  document 
based  on  the  IEEE  802.10  Key  Management  Group  [Ref.  Curcio  1994] 

Generic  Abstract  Services  for  Security  (GASS).  While  the  primary  basis  of  work 
on  authentication  will  be  ISO  9594-8,  it  is  anticipated  that  ECMA-138  (see  Section  1 1.2.4.3)  will 
also  provide  a  useful  basis  for  these  services.  The  strawraan  document  for  Part  2  of  the  standard. 
Generic  Abstract  Services  for  Security  (GASS)  is  SC21/WG8  N  173,  November  1993. 
ECMA/TC36-TC9  has  contributed  an  early  draft  of  a  three-part  standard  on  Authentication  and 
Privilege  Attribute  Security  Application  with  Related  Key  Distribution  Functions, 
November  1993.  The  three  parts  are  Overview  and  Functional  Model  [SC21  N  8325],  Security 
Information  Objects  [SC21  N  8326],  and  Service  Definitions  [SC21  N  8327]. 

Authentication  for  Lower  Layers.  SC21/WG8  has  noted  that  the  authentication  is 
aimed  primarily  for  upper  layer  security  protocols,  it  is  also  expected  to  support  the  lower  layer 
security  protocols.  The  concept  of  a  security  association  will  be  a  central  concept,  defined  as  a 
relationship  between  two  or  more  entities  for  which  there  exist  attributes  (static  and  dynamic 
information  and  rules)  to  govern  the  provision  of  security  services  involving  those  entities.  [Ref. 
SC21  N  7915  1993] 

11.2.3  Security  Standards  Work  in  NATO 

11.2.3.1  TSGCE  SG9  AHWG  on  Security 

The  TSGCE  SG9  Ad  Hoc  Working  Group  (AHWG)  on  Security  developed  the  NOSA  and 
SANISI  documents  (identified  in  Section  1 1.2.1  above),  whereas  the  security  annexes  for  the  layer 
STANAGs  are  the  responsibility  of  TSGCE  SG9/WG5  and  SG9/WG6.  NOSA  was  developed  to 
give  guidance  to  contractors  and  procurement  managers  on  the  preferred  placement  of  security 
services  within  OSI-conformant  systems.  SANISI  provides  more  detailed  rationale  on  the 
placement  of  security  services  and  mechanisms  within  the  NATO  OSI  Reference  Model.  Section 

17.3.5.1  provides  a  description  of  the  current  work  of  the  AHWG  on  Security. 

11.2.3.2  NATO  OSI  Security  Architecture  (NOSA) 

NOSA  identifies  OSI  security  services  for  the  Physical,  Network,  and 
Presentation/Application  Layers.  These  are  [Ref.  NOSA  1988]: 

•  Physical  Layer  will  provide  two  services  by  transparent  means  without  requiring 
modifications  to  the  Physical  Layer  protocols: 

Connection  confidentiality,  which  is  capable  of  dealing  with  circumstances  where 
the  physical  communication  is  intermittent  or  asymmetric. 

Traffic  flow  confidentiality. 

•  Network  Layer  security  services  are  provided  within  subnetwork-dependent  roles  and 
within  a  TCS: 

Subnetwork-dependent  services  are  peer  entity  authentication,  data  origin 
authentication,  access  control,  connection  confidentiality,  connectionless 
confidentiality,  traffic  flow  confidentiality,  connection  integrity  without  recovery, 
and  connectionless  integrity. 

Security  services  that  can  be  provided  by  the  NATO  TCS  are  identical  to  the  eight 
identified  above  for  subnetwork-dependent  roles. 
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•  Presentation/Application  Layers  could  provide  as  many  as  14  security  services: 

The  eight  services  identified  above  for  the  Network  Layer. 

The  following  additional  six  services:  selective  field  confidentiality,  connection 
integrity  with  recovery,  selective  Held  connection  integrity,  selective  field 
connectionless  integrity,  non-repudiation  with  proof  of  origin,  and  non¬ 
repudiation  with  proof  of  delivery. 

NOSA  is  the  basis  for  Part  2  of  the  NATO  OSI  Reference  Model  (STANAG  4250-2): 
Security,  Version  4.0,  9  December  1993.  Draft  STANAG  4250-2  supersedes  NOSA. 
Documentation  of  the  NATO  security  architecture  for  voice  and  video  communications  (e.g., 
ISDN)  is  being  developed  separately  and  may  become  a  supplement  to  STANAG  4250-2. 

11.2.4  Other  Security  Standards  Work 

11.2.4.1  Secure  Data  Network  System  (SDNS) 

The  Secure  Data  Network  System  (SDNS)  was  established  in  1986  as  a  partnership 
between  NSA  and  10  major  computer  and  telecommunications  companies,  including  AT&T, 
Digital  Equipment  Corporation,  and  IBM,  with  the  goal  of  developing  a  security  architecture  based 
on  the  OSI  model  and  using  a  distributed  key  generation  system  in  which  computus  are  able  to 
establish  cryptographic  keys  as  needed  to  communicate  with  other  computers.  [Ref.  RNLA  1994, 
p.  126]  The  goals  of  SDNS  were  to  create  specifications  for  end-to-end  security;  to  use  the  OSI 
Reference  Model;  to  design  an  architecture  to  include  electronic  mail  and  end-to-end  encryption;  to 
provide  transparent  key  management;  and  to  demonstrate  feasibility  of  techniques.  The  US 
National  Security  Agency  (NSA)  supported  the  SDNS  project,  which  has  released  to  the  public 
domain  several  standards  for  security  protocols  [Ref.  NSA  1989  and  1989  a-j].  (SDNS  is  no 
longer  being  actively  supported  by  NSA — all  work  related  to  SDNS  has  now  been  referenced  to 
NLSP,  TLSP,  and  the  Message  Security  Protocol  (MSP). 

SP3  and  SP4  have  been  introduced  into  the  ISO  voluntary  standard  process  by  ANSI.  SP3 
has  evolved  into  ISO  1 1577,  Network  Layer  Security  Protocol  (NLSP)  and  SP4  has  evolved  into 
ISO  10736,  Transport  Layer  Security  Protocol  (TLSP).  Even  though  the  protocols  have  retained 
the  same  functionality  as  their  SDNS  counterparts,  changes  introduced  during  the  standards 
process  have  made  NLSP  non -interoperable  with  SP3  and  TLSP  non-interoperable  with  SP4.  The 
SDNS  standards  for  SP3,  SP4,  MSP,  and  others  is  provided  in  Table  35. 

Some  of  the  differences  between  the  international  standard  protocols  (NLSP  and  TLSP) 
and  the  SDNS  protocols  are  as  follows  [Ref.  Walters  1993]: 

•  NLSP  and  TLSP  use  variable-length  fields  to  carry  Type,  Length,  and  Value  data  in 
each  Protocol  Data  Unit  (PDU)  while  SP3  and  SP4  use  fixed-length,  fixed-position 
fields.  This  gives  NLSP  and  TLSP  greater  flexibility  (and  higher  overhead)  since  field 
lengths  can  be  changed  and  field  order  varied  by  making  a  parameter  change  rather 
than  redefining  the  protocol. 

•  SP3  supports  DoD  IP  using  the  SP3-D  variant  in  addition  to  the  ISO  Connectionless 
Network  Protocol  (CLNP)  (ISO  8473).  NLSP  only  supports  CLNP.  SP3  support 
for  DoD  IP  is  critical  to  the  US  Government's  installed  base  of  end  systems  that 
implement  DoD  IP.  However,  as  new  procurements  filed  US  GOSIP-compliant  end 
systems,  the  proportion  of  DoD  IP  end  systems  is  expected  to  shrink  relative  to  ISO 
CLNP  end  systems. 

•  NLSP  can  support  Connection  Oriented  Network  Service  (CONS)  whereas  SP3 
cannot 
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•  NLSP  and  TLSP  support  Security  Association  (SA)  -  Protocol  (SA-P)  as  an  option 
that  allows  NLSP  and  TLSP  peer  entities  to  exchange  information  needed  for  SA 
establishment  and  rekeying  during  the  lifetime  of  an  SA  and  an  SA  release. 

•  TLSP  uses  double  encapsulation,  which  increases  overhead.  # 

•  SP4  has  an  optional  Final  Sequence  Number  (FSN)  field  in  the  protected  header.  SP4 
validates  the  FSN  to  ensure  complete  shut  down  of  a  session.  TLSP  does  not  support 
FSN,  leaving  this  function  to  the  session  layer  protocol.  This  raises  prospects  of 
allowing  successful  attacks  if  the  session  layer  does  not  ensure  that  die  last  packet  of  a 
connection  has  been  properly  received  and  acknowledged.  However,  specifying  a 

properly  implemented  session  layer  protocol  above  TLSP  will  provide  the  same  * 

service  as  FSN. 

•  TLSP  can  support  protected  header  field  sizes  up  to  65,535  octets,  while  SP4  can  only 
support  sizes  up  to  254  octets.  However,  the  SP4  protected  header  field  is  followed 
by  an  encapsulated  Transport  PDU  of  unlimited  length.  This  larger  protected  content 

field  size  supported  by  SP4  provides  a  more  efficient  data  transfer  method  than  TLSP  • 

since  more  data  can  be  carried  in  each  SP4  Secure  Data  Unit." 


Table  35.  Security  Protocols  Developed  in  SDNS 


•  Security  Protocol  3  (SP3).  Provides  various  security  services  in  the  Network  Layer  through  the  use  of 
cryptographic  mechanisms;  SP3  is  a  subnetwork  independent  convergence  protocol  (SNICP,  ISO  8648)  that 
extends  the  CLNS  (ISO  8348/ADI)  with  confidentiality  (protection  against  passive  monitoring),  integrity 
(protection  against  modification,  replay,  addition,  or  deletion),  or  both.  SP3  is  designed  to  be  used  at  the  top  of 
Layer  3  [Ref.  NSA 1989]. 

•  Security  Protocol  4  (SP4).  Specifies  optional  extensions  of  the  COTS  (ISO  8072)  and  connectionless  transport 
service  (ISO  8072/ADl )  for  the  Transport  Layer.  The  extensions  permit  the  use  of  cryptographic  techniques  to 
provide  data  protection  for  transport  connections  for  connectionless-mode  Transport  Protocol  Data  Unit  (TPDU) 
transmission.  SP4  can  be  used  with  the  CONS  or  the  CLNS.  SP4  is  designed  to  be  used  at  the  bottom  of  Layer  4 
[Ref.  NSA  1989a]. 

•  Massage  Security  Protocol  (MSP).  Defines  additions  to  the  ITU-TS  X.400  (either  1984  or  1988)  that  permit  any 
type  of  message  (including  interpersonal  messages)  to  be  sent  and  received  secure ly.  When  used  with  the 
conventions  defined  by  ANSI  for  the  X.400  Message  Transfer  System,  MSP  can  be  used  to  exchange  EDI 
messages  securely.  The  MSP  provides  writer-to-reader  confidentiality,  access  control  for  message  transfer, 
and  request  for  a  signed  receipt  of  the  received  message.  SON  701  [Ref.  NSA  1969c]  specifies  the  MSP,  and 
SDN  702  [Ref.  NSA  1989d]  defines  new  attribute  types  and  object  classes  for  inclusion  in  the  X.500  Directory  in 
support  of  key  management  functions  used  by  MSP. 

•  Key  Management  Protocol.  Key  management  provides  for  the  generation,  distribution,  and  updating  of  traffic 
encryption  keys  (TEKs).  The  abstract  model  for  a  Kay  Management  Application  Process  (KMAP)  consists  of  two 
parts;  the  information  processing  part  that  is  supported  by  Management  Information  Bases  (MIBs)  for  keys  and 
for  TEKs.  and  the  communication  part,  caled  the  Key  Management  Application  Entity  (KMAE).  The  KMAE 
consists  of  the  Layer  7  ACSE  (ISO  8649)  and  a  Key  Management  Application  Service  Element  (KMASE).  The 
Key  Management  Protocol  provides  Layer  7  peer-level  services  between  the  KMASEs  of  two  KMAPs.  The  Key 
Management  Protocol  assumes  the  use  of  the  connection-oriented  presentation  services  (ISO  8822)  [Ref.  NSA 
1986b;  NSA  1989h;  NSA  1989i;  NSA  1989j). 

•  Access  Control.  Access  control  is  the  prevention  of  the  unauthorized  use  of  a  resource,  including  the 
prevention  of  use  of  a  resource  in  an  unauthorized  manner  (ISO  7498-2).  SDN  801,  SDN  802,  and  SDN  802/1 
[Ref.  NSA  1989s;  NSA  1989f;  NSA  1989g]  specify  an  access  control  framework  based  on  a  four-tiered  model 
and  an  Access  Control  Information  System  (ACIS)  that  provides  a  uniform  method  for  encoding  access  control 
information  that  is  independent  of  any  particular  security  policy.  The  ACIS  also  provides  a  standard  algorithm  for 
interpreting  and  comparing  access  control  attributes.  The  access  control  framework  provides  for  authentication 
data  and  access  control  checks  that  wi  alow  communication  between  dffierent  SDNS  users/systems  when  their 
respective  security  poicies  allow  it.  The  framework  provides  two  processes:  a  Peer  Access  Approval  process 
for  interpreting  the  data  of  the  four-tiered  mode,  and  the  Peer  Access  Enforcement  Process  for  enforcing 
access  control  on  a  Protocol  Data  Unit  (PDU)  basis  [Ref.  NSA  1989e;  NSA  1989f;  NSA  1989g}. 
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11.2.4.2  NIST  Recommendations 

The  NIST  approach  to  OSI  security  standards  includes  the  following  features 
[Ref.  DCA  1989a]: 

•  Security  encapsulation  standard  to  provide  cryptographic  protection  of  integrity  and 
confidentiality.  A  common  format  and  processing  standard  is  needed  that  is 
independent  of  the  algorithm  to  be  used. 

•  Mail  handling  security  system  for  MHS,  to  be  used  between  the  User  Agent  and  the 
Transfer  Agent  to  encapsulate  the  entire  message  contents;  this  requires  posted  keys 
and  certificates.  (One  candidate  is  from  X.41 1 ;  another  is  the  MSP  from  SDNS.) 

•  Cryptographic  key  management,  a  service  to  be  provided  at  the  Application  Layer  to 
support  real-time  (SP3  and  SP4)  as  well  as  posted  (MHS)  requirements.  FIPS  171, 
Key  Management  Using  ANSI  X9.I7,  was  approved  in  April  1992. 

•  Security  labels  and  labelling.  These  are  planned  to  be  strongly  coupled  with  data. 

•  Authorization  and  access  control.  These  features  would  permit  policies  to  be  specified 
within  security  domains  and  would  support  multiple  policies  and  models  (candidates 
are  from  ECMA  and  SDNS). 

The  NIST  data  encryption  FIPS  are  as  follows: 

•  FIPS  46-1,  Data  Encryption  Standard  (DES),  January  1988  (reaffirmed  until  1992). 
This  standard  specifies  an  algorithm  to  be  implemented  in  electronic  hardware  devices 
and  used  for  the  cryptographic  protection  of  computer  data.  The  algorithm  uniquely 
defines  the  mathematical  steps 'required  to  transform  computer  data  into  a 
cryptographic  cipher  and  the  steps  required  to  transform  the  cipher  back  to  its  original 
form.  This  standard  has  been  adopted  as  a  voluntary  industry  standard, 
ANSI  X3.92-1981.64  DES  guidelines  are  provided  by  FIPS  74. 

•  FIPS  81,  DES  Modes  of  Operation,  December  1980.  This  standard  defines  four 
modes  of  operation  for  the  DES  that  may  be  used  in  a  wide  variety  of  applications. 
The  modes  specify  how  data  will  be  encrypted  (cryptographically  protected)  and 
decrypted  (returned  to  original  form).  This  standard  has  been  adopted  as  a  voluntary 
industry  standard,  ANSI  X3. 106- 1983. 

•  FIPS  1 13,  Computer  Data  Authentication,  May  1985.  This  standard  specifies  a  Data 
Authentication  Algorithm  (DAA)  that,  when  applied  to  computer  data,  automatically 
and  accurately  detects  unauthorized  modifications,  both  intentional  and  accidental. 
Based  on  FIPS  46,  this  standard  is  compatible  with  requirements  adopted  by  the 
Department  of  Treasury  and  the  banking  community  to  protect  electronic  fund  transfer 
transactions. 

•  FIPS  139,  Interoperability  and  Security  Requirements  for  Use  of  the  Data  Encryption 
Standard  in  the  Physical  Layer  of  Data  Communications,  August  1983.  This  standard 
facilitates  the  interoperation  of  government  data  communication  facilities,  systems,  and 
data  that  require  cryptographic  protection  using  the  DES  algorithm.  The  standard 
specifies  interoperability  and  security  related  requirements  using  encryption  at  the 
physical  layer  of  the  OSI  Reference  Model  in  the  telecommunication  systems 
conveying  Automatic  Data  Processing  and/or  narrative  text  information.  It  is  the  same 
as  US  Federal  Standard  1026  and  ANSI  X3. 105- 1983. 

•  FIPS  140-1,  Security  Requirements' for  Cryptographic  Modules,  Equipment,  Draft 
May  1993.  This  standard  prescribes  security  requirements  for  specifying 
cryptographic-based  security  systems  used  to  provide  protection  for  sensitive  or 
valuable  data.  Protection  of  cryptographic  modules  within  a  security  system  is 


64  A  list  of  ANSI  standards  it  given  in  Section  IV .C  of  Appendix  H. 
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necessary  to  maintain  the  confidentiality  and  integrity  of  the  information  protected  by 
die  module.  The  standard  specifies  the  security  requirements  that  are  to  be  satisfied  by 
a  cryptographic  module.. 

•  FIPS  141,  Interoperability  and  Security  Requirements  for  Use  of  the  Data  Encryption 
Standard  with  ITU-TS  Group  3  Facsimile  Equipment,  April  1985.  This  standard 
specifies  interoperability  and  security-related  requirements  for  use  of  encryption  with 
the  ITU-TS  Group  3- type  facsimile  equipment  conveying  Automatic  Data  Processing 
(ADP)  and/or  narrative  text  information.  It  is  the  same  as  US  Federal  Standard  1028. 

•  Digital  Signature  Standard  (DSS).  This  standard  satisfies  the  US  Government's  needs 
for  cryptographic  message  authentication  to  protect  its  unclassified  and  unclassified  but 
sensitive  information  processing  infrastructure.  DSS  provides  required  authentication 
and  non-repudiation  services  without  unnecessarily  putting  trust  in  processing 
components. 

•  Common  IP  Security  Option  (CIPSO)  Labeling  Standard.  The  CIPSO  allows  the 
attachment  of  specific  security  attributes  associated  with  the  data  in  an  IP  datagram. 
These  data  are  used  to  perform  decisions  at  the  IP  layer.  This  document  defines  the 
basic  format  and  processing  procedures  for  the  CIPSO.  In  addition,  it  defines  the 
specific  attribute  formats  and  procedures  to  support  the  standard  DoD  Mandatory 
Access  Control  Security  Policy.  A  FIPS  based  on  this  DoD  standard  is  in  preparation. 

Finally,  NIST  is  developing  techniques  outside  the  OSI  model  for  personal  identification 
and  authentication.  Approaches  include  knowledge,  token,  or  physical  means.  Technologies 
being  considered  include  a  smart  card  and  use  of  passwords.  A  NIST  workshop  in  September 
1990  addressed  integrity  guidelines. 

The  current  concentration  of  NIST  is  on  beginning  the  development  of  a  new  set  of 
Information  Security  Product  Evaluation  Criteria,  better  known  as  the  Federal  Criteria.  The  first 
public  draft  of  Federal  Criteria  (FC)  for  Information  Technology  (IT)  Security  was  distributed  in 
January  1993  for  review  and  comment  The  FC  is  the  result  of  an  ongoing  joint  effort  between 
NIST  and  NSA.  The  FC  is  expected  to  evolve  into  a  new  FIPS  and  once  approved  will  replace 
DoD  5200.28-STD  Trusted  Computing  Systems  Evaluation  Criteria  (TCSEC)  or  the  Orange  Book. 
The  FC  is  published  in  two  volumes.  Volume  I  discusses  Protection  Profile  Development  and 
Volume  II  describes  the  Registry  of  Protection  Profiles.  Protection  Profiles  specify  baseline 
requirements  that  meet  generally  accepted  security  enforcing  functions  with  broad  applicability  and 
effectiveness.  (Ref.  CFS  1993J 

The  FC  for  IT  Security  provides  a  conceptual  framework  for  defining  requirements  for 
trusted  product  development  and  evaluation.  The  framework  is  based  on  the  definition  of  generic 
requirements  for  security  functionality  and  security  assurance  expressed  as  primitive  components 
or  building  blocks.  The  components  can  be  combined  into  composite  groups  of  requirements,  or 
packages,  and  used  to  create  unique  sets  of  IT  product  security  criteria  called  protection  profiles. 
The  protection  profile  provides  the  principal  vehicle  for  customer-defined  security  requirements 
for  IT  products  to  include  the  specification  of  security  features,  development  assurance,  and 
evaluation  assurance.  The  protection  profile  requirements  for  a  particular  class  of  IT  products  are 
described  in  the  context  of  an  assumed  environment  of  use  and  set  of  generalized  threats.  The 
Federal  Criteria  builds  on  national  and  international  IT  product  security  research  and  development 
by  bringing  together  and  extending  many  concepts  of  previous  work.  While  preserving  the 
fundamental  principles  of  IT  product  security,  the  Federal  Criteria  provides  an  extensible  and 
flexible  framework  for  defining  new  requirements  as  technology  advances  and  the  needs  of  the 
customer  change.  The  criteria  also  provides  the  basis  for  international  harmonization  of  IT  product 
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security  evaluation  criteria,  an  important  factor  in  motivating  the  development  of  cost-effective, 
commercial-off-the-shelf  products  by  US  vendors. 

The  OIW  has  a  Special  Interest  Group  (SIG)  on  OSI  Security  Architecture.  The  purpose  of 
this  group  is  to  develop  an  overall  OSI  security  architecture  that  is  consistent  with  the  OSI 
Reference  Model  and  that  economically  satisfies  the  primary  security  needs  of  both  the  commercial 
and  Government  sectors.  The  SIG  on  OSI  Security  Architecture  plans  to  address  key  management 
and  security  management  functions  that  must  be  performed  between  the  layers  and  die  peer  entities 
defined  in  the  OSI  architecture. 

NIST  Special  Publication  800-4,  Computer  Security  Considerations  in  Federal 
Procurements  helps  procurement  initiators,  contracting  officers,  and  computer  security  officials 
understand  the  concepts  for  integrating  computer  security  into  agency  acquisitions  and  for  selecting 
needed  computer  security  features,  assurances,  and  procedures.  [Ref.  CSL  1992, 4] 

11.2.4.3  ECMA  Recommendations 

In  December  1989,  ECMA  issued  a  standard  (ECMA  138)  entitled  Security  in  Open 
Systems — Data  Elements  and  Service  Definition.  It  is  based  on  ECMA  TR  46,  Security 
Framework  [Ref.  ECMA  1988],  which  describes  a  framework  for  the  development  of  security 
provisions  in  the  Application  Layer.  ECMA  138  defines  data  elements  and  services  for  support  of 
a  multi-user,  multi-vendor,  distributed  system  environment 

While  ECMA  138  addresses  security  in  distributed  systems,  ISO  7498-2  addresses  only 
communications  security.  Moreover,  ECMA  and  ISO  terminology  are  not  consistent  ISO  defines 
five  security  services  and  discusses  them  in  terms  of  the  mechanisms  that  may  be  used  to 
implement  the  services  and  the  layer  of  the  ISO  model  where  they  may  be  appropriately 
implemented.  ECMA  defines  eight  different  security  services  and  eight  security  facilities  they 
contain.  However,  the  ECMA  model  deals  primarily  with  two  of  the  five  services  defined  in 
ISO  7498-2:  authentication  and  access  control.  [Ref.  Burr  1991] 

11.2.4.4  IEEE  Work  on  Secure  Local  Area  Networks  (LANs) 

IEEE  is  developing  standards  for  secure  LANs.  The  draft  standards  provide  different 
service  interfaces  for  key  management,  secure  data  exchange,  and  security  management: 

•  IEEE  P8G2. 10A,  Interoperable  LAN  Security  ( SILS)  -  The  Model 

•  IEEE  802.10B,  SILS  - Secure  Data  Exchange  (SDE) — a  data  link  layer  protocol 
providing  confidentiality,  integrity,  data  origin  authentication,  and  access  control 
services,  1992 

•  IEEE  P802.10C,  SILS  -  Key  Management,  Draft,  September  1993 — an  application 
layer  function  that  supports  SDE  by  specifying  a  cryptographic  key  management 
model  and  protocol  [Ref.  IEEE  SILS  1993] 

•  IEEE  P802.10D,  SILS  -  Security  Management — an  application  layer  set  of  services 
used  to  manage  the  security  protocols. 

Security  management  may  be  expanded  to  include  fault,  performance,  and  configuration 
management  as  well.  In  addition,  IEEE  P802.2  is  considering  an  optional  security  sublayer  for 
logical  link  control.  [Ref.  LLC  1988] 


11.2.4.5  BLACKER 

On  the  Defense  Integrated  Secure  Network  (DSNET),  the  Defense  Information  Systems 
Agency  (DISA)  operates  a  standard  end-to-end  encryption  (E3)  system  called  BLACKER.  A 
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BLACKER  front  end  (BFE)  device  is  installed  on  each  host-to-switch  access  path  of  all  hosts  used 
by  subscribers,  including  terminal  access  controllers.  The  BLACKER  system  includes  key 
distribution  center  (KDC)  and  access  control  center  (ACC)  hosts  that  automatically  manage 
encryption  keys  via  DSNET.  BLACKER  ensures  that  no  network  malfunction  can  permit  or  cause 
an  unencrypted  packet  to  be  delivered  to  a  host  not  authorized  to  receive  it  [Ref.  DCA  1990; 
Shineyn.d.;  DCA  1989b] 

BLACKER  is  designed  to  satisfy  Class  A1  of  the  DoD  Trusted  Computer  System 
Evaluation  Criteria  (TCSEC),  also  known  as  "the  Orange  Book,"  by  encrypting  the  application 
data  in  each  X.25  packet  while  leaving  header  data  unencrypted  for  backbone  use.  BLACKER 
makes  DSNET  multilevel  secure  in  three  ways.  First,  BLACKER  separates  subscriber  security 
communities  from  each  other,  allowing  the  DSNET  communities  to  share  one  backbone.  Second, 
on  the  host  side,  the  BFE  recognizes  a  security  label  on  each  packet,  allowing  DSNET  to  serve  a 
multilevel  secure  host  through  one  BFE.  Third,  BLACKER  separates  the  entire  host  community 
on  one  side  of  the  BFEs  from  die  backbone  on  the  other,  allowing  the  backbone  to  operate  at  a 
lower,  less  costly  security  level. 

The  host  interface  to  the  BFE  is  based  on  standards  defined  for  the  1983  DDN  X.25 
interface,  and  requires  that  the  Internet  Protocol  (IP)  be  used  as  the  next  layer  above  X.25.  The 
BFE  presents  a  Data  Circuit-Terminating  Equipment  (DCE)  interface  to  the  host.  Only  DDN 
"Standard  Service"  X.25  is  offered  at  the  host  interface;  no  provisions  for  "Basic  Service"  will  be 
matte.  The  BLACKER  interface  is,  however,  neither  a  pure  X.25  interface  nor  a  mere  subset  of 
X.25,  but  rather  must  be  developed  from  X.25  interfaces. 

The  BFE  conforms  to  the  following  Layer  3  specifications  [Ref.  DCA  1989b]: 

•  Defense  Data  Network  X.25  Host  Interface  Specification,  DCA,  December  1983 

•  Interface  Between  Data  Terminal  Equipment  (DTE)  and  Data  Circuit  Termination 
Equipment  (DCE)  for  Terminals  Operating  in  the  Packet  Mode  on  Public  Data 
Networks,  Recommendation  X.25,  ITU-TS,  1980 

•  WD2512  X.25  Packet  Network  Interface  (LAPB),  Western  Digital  Corporation,  1989. 

In  the  Fall  of  1989,  a  multi-Service  demonstration  that  used  BLACKER  communications 

security  and  off-the-shelf  gateways  and  routers  was  held  in  the  United  States.  The  Integrated 
Tactical-Strategic  Demonstration  Network  (ITDN)  used  only  non-developmental  item  components, 
standard  data  communications  protocols  (X.25  with  TCP/IP),  and  existing  military 
communications  systems.  ITDN  interconnected  automated  systems  at  multiple  echelons  at  widely 
dispersed  (over  1,000  miles)  locations  with  multiple-security-level  interconnected  networks. 

Work  similar  to  BLACKER  is  being  done  in  other  NATO  nations  to  achieve  the  same  ends. 

11.2.4.6  Computer  Security  (COMPUSEC)  Guidance 

In  order  to  guarantee  secure  handling  of  data  and  information  technology  systems,  it  is 
necessary  to  comply  with  security  standards  appropriate  to  the  respective  risks  in  differing 
operational  environments.  Commonly  referenced  security  standards  for  COMPUSEC  guidance  are 
(Ref.  CSC  1985;  CSC  1985a;  CSC  1985b;  CSC  1987,  ITSEC  1990): 

•  Computer  Security  Requirements — Guidance  for  Applying  die  Department  of  Defense 
Trusted  Computer  System  Evaluation  Criteria  in  Specific  Environments  (Yellow 
Bode),  issued  by  the  DoD  Computer  Security  Center  (DoDCSC)  in  June  1985 

•  Technical  Rationale  Behind  CSC-STD-003-85:  Computer  Security  Requirements— 
Guidance  for  Applying  the  Department  of  Defense  Trusted  Computer  System 
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Evaluation  Criteria  in  Specific  Environments  (Yellow  Book  Rationale),  issued  by 
DoDCSC  in  June  1985 

•  Department  of  Defense  Trusted  Computer  System  Evaluation  Criteria  (Orange  Book), 
issued  under  the  authority  and  in  accordance  with  DoD  Directive  5200.28  in  December 
1985.  Its  purpose  is  to  provide  technical  hardware/firmware/software  security  criteria 
and  associated  technical  evaluation  methodologies  in  support  of  the  overall  ADP 
system  security  policy,  evaluation  and  approval/accreditation  responsibilities 
promulgated  by  DoD  Directive  5200.28,  "Security  Requirements  for  Automatic  Data 
Processing  (ADP)  Systems."  The  trusted  computer  system  evaluation  criteria  classify 
systems  into  four  broad  hierarchical  divisions  of  enhanced  security  protection: 
minimal,  discretionary,  mandatory,  and  verified. 

•  Trusted  Network  Interpretation  (Red  Book),  issued  by  the  National  Computer  Security 
Center  in  July  1987 

•  Information  Technology  Security  Evaluation  Criteria  (ITSEC)— Harmonised  Criteria 
of  France,  Germany,  The  Netherlands,  and  the  United  Kingdom,  Draft,  Version  1, 
May  1990. 

11.2.4.7  ITU-TS  Proposed  Question  on  Security 

ITU-TS  Question  Q19/VII,  proposed  for  the  1993-96  study  period  concerns  the 
continuation  of  work  to  date  in  security.  While  X.200  (Reference  Model  of  OSI  for  ITU-TS 
Applications)  and  X.800  (Security  Architecture  for  Open  Systems  Interconnection  for  ITU-TS 
Applications)  describe  security  within  the  context  of  the  open  systems  reference  model,  there  is  a 
need  for  a  comprehensive  set  of  more  detailed  frameworks  covering  aspects  of  security  such  as 
authentication,  access  control,  confidentiality,  etc.,  together  with  mechanisms,  services,  and 
protocols  necessary  to  implement  these  models  in  both  open  systems  in  general  and  ITU-TS 
applications  pertaining  to  the  evolution  of  networks,  systems,  and  services.  Specifically,  what 
new  recommendations,  if  any,  are  needed: 

•  To  describe  open  systems  security  frameworks? 

•  To  describe  open  systems  interconnection  generic  upper  layers  security  facilities  in  die 
application  and  presentation  layers? 

•  To  describe  information  technology  security  techniques? 

•  To  satisfy  tire  security  requirements  of  administrations  and/or  users  who  apply  the 
open  systems  interconnection  family  of  recommendations? 

Moreover,  what  changes  or  enhancements  should  be  made  to  Recommendation  X.509  to  correct 
deficiencies  and/or  better  relate  it  to  any  new  recommendations  developed  under  this  question? 
Finally,  what  changes  or  enhancements,  if  any,  would  be  made  to  X.800?  [Ref.  SC21  N  6956 
1992] 

11.2.4.8  DoD  Goal  Security  Architecture 

The  DoD  Goal  Security  Architecture  [DGSA,  formerly  the  Defense-Wide  Information 
Systems  Security  Program  (DISSP)  Goal  Security  Architecture]  [Ref.  DGSA  1993]  establishes  the 
conceptual  target  for  all  DoD  information  security  architectures.  It  is  integrated  into  the  TAFIM, 
providing  an  integrated  architectural  focus,  and  providing  guidance  to  security  architects  (i.e.,  it 
provides  abstract  architectural  concepts  of  security  to  be  embodied  in  specific  information  system 
architectures).  A  companion  effort,  the  DGSA  Overall  Transition  Strategy  (DOTS),  addresses  the 
Defense-wide  transition  toward  tire  incorporation  of  DGSA-specified  security  concepts  into  current 
and  new  information  system  architectures. 
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11.2.4.9  Kerberos 

Kerberos  is  an  authentication  system  for  open  systems  and  networks.  Developed  by 
project  Athena  at  MTT,  Kerberos  can  be  added  onto  many  existing  network  protocols.  It  has  been 
used  with  UNIX-oriented  protocols  such  as  Sun’s  Network  File  System  (NFS).  Each  user  has  a 
private  authentication  key.  Kerberos  guards  the  data  transmitted  between  machines  that 
communicate  over  the  network  and  uses  cryptographic  keys  known  as  tickets  to  protect  the  security 
of  messages  a  user  sends  to  the  system  (and  the  messages  the  system  sends  back  to  the  user).  It 
never  transmits  passwords,  even  in  encrypted  form,  on  the  network.  Passwords  reside  only  in  a 
highly  secure  machine  called  a  key  server.  Kerberos  performs  authentication  both  when  a  user 
logs  into  die  system  and  when  the  user  requests  any  type  of  network  service. 

11.2.4.10  Secure  Network  File  System 

Sun  Microsystem’s  Network  File  System  (NFS  has  become  a  de  facto  standard  for  UNIX 
systems.  NFS  allows  a  client  system  to  mount  devices  on  a  file  server  as  if  the  server  were 
physically  connected  to  the  system.  Secure  NFS  uses  two  types  of  encryption:  the  data  encryption 
standards  (DES),  a  private  key  system)  and  a  public  key  encryption  system. 

11.2.4.11  Multi-Level  Security  for  Database  Management 

Government  and  industry  are  actively  pursuing  the  development  of  multilevel  security 
capabilities.  In  the  context  of  database  management,  the  term  multilevel  security  (MLS)  refers  to 
the  ability  of  a  system  to  simultaneously  process  data  of  various  sensitivities  without  risk  of 
compromise.  Mandatory  access  control  (MAC),  with  which  separation  of  sensitive  data  and  access 
to  that  data  is  always  automatically  enforced,  is  the  key  component  of  multilevel  secure  systems. 
MAC  provides  a  means  of  controlling  access  to  data  based  on  the  sensitivity  of  the  data,  as 
represented  by  a  label,  and  on  the  formal  authorization  or  clearance  of  the  user  attempting  to  access 
the  data.  Each  row  of  data  within  the  database  contains  a  label  that  represents  the  sensitivity  of  that 
row.  In  most  MLS  implementations,  users  can  normally  write  information  at  a  sensitivity  label 
equal  to  their  own  sensitivity  labels,  and  can  read  information  at  labels  equal  to  or  less  sensitive 
than  their  own  sensitivity  labels. 

Current  examples  of  industry-led  multilevel  security  development  efforts  are  Trusted 
ORACLE?,**  which  is  designed  to  meet  Class  Bl,  and  ORACLE7,  which  is  designed  to  meet 
Class  C2  of  the  US  Government's  Trusted  Computer  System  Evaluation  Criteria  (TCSEC;  Orange 
Book).  Trusted  ORACLE7  is  also  designed  to  meet  F-B1/E3  of  the  European  Information 
Technology  Security  Evaluation  Criteria  (ITSEC).  Trusted  ORACLE7  is  designed  to  be  a  full- 
function,  open  RDBMS;  it  adheres  to  standards  such  as  ISO/ANSI  SQL. 

11.3  Assessment  of  Coverage  by  Standards 

While  there  is  a  great  deal  of  activity  in  standards  for  security  services,  there  is  very  litde 
that  is  complete.  The  most  mature  technical  areas  are  operating  system  and  physical  layer  network 
standards,  but  even  here  the  standards  are  not  mature.  Security  in  most  other  aspects  still  contains 
areas  of  basic  research.  The  standards  that  have  been  approved  are  generally  the  umbrella 
standards,  such  as  ISO  7498-2. 
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12.  SYSTEM  MANAGEMENT  SERVICE  STANDARDS 

This  chapter  summarizes  the  status  of  standards  in  four  -  ■  ■  ■  - - ■ 

areas:  network  (OSI)  management,  registrauon  authonues,  - ip~~j 

conformance  testing,  and  formal  description  techniques  (FDTs).  Assessment  283 

Appendix  F  identifies  organizations  and  standards  bodies  that  CMIS/P  27i 

have  contributed  to  development  of  these  standards.  Conformance  Testing  282 

Estelle  288 

Standards  for  OSI  management  are  described  first  fot,  288 

(Section  12.1).  These  are  followed  by  standards  for  G -LOTOS  291 

conformance  testing  (Section  12.2)  and  registration  authorities  LOTOS  290 

(Section  12.3).  FDTs  are  addressed  with  conformance  testing  Man^ememS^s  Mi 

standards  in  Section  12.2.  OSI  Management  261 

PICS  Proformas  288 

12.1  Status  of  Standards  for  Network  Management  QoS  27g 

This  section  discusses  the  status  of  OSI  network  Registration  Authorities  282 

management  standards,  the  Telecommunications  Management  Sy^wrns  MamMemem  274 

Network  (TMN),  military  concerns  in  network  management  277 

including  quality  of  service  (QoS)  issues,  the  special  interest  Z  Description  Language  291 

groups  (SIGs)  for  OSI  management,  the  ECMA  Model  for 
Management,  and  the  Simple  Network  Management  Protocol 
(SNMP). 

Part  4  of  the  OSI  Reference  Model,  Management  Framework  (ISO  7498-4)  identifies  three 
areas  of  OSI  management:  systems  management,  layer  management,  and  application  process 
management  Development  of  international  civil  standards  for  the  overall  management  architecture 
and  for  systems  management  is  being  coordinated  through  SC21/WG4  on  OSI  Management  The 
United  States  has  developed  a  FIPS,  (FIPS  179),  Government  Network  Management  Profile 
(GNMP),  issued  December  1992  based  on  this  management  framework.  While  a  few  products 
implement  parts  and  subsets  of  the  specification,  NIST  expects  full  implementations  to  be  available 
in  1993.  (Ref.  APP  1992] 

Figure  14  identifies  the  classes  of  OSI  management  standards  and  indicates  the 
relationships  among  these  classes.  ISO  standards  are  identified  where  they  apply. 

Work  is  progressing  in  SC6/WG2  and  SC6/WG4  on  OSI  management  in  the  lower  layers. 
An  international  specification  (ISO/IEC  10733)  of  the  elements  of  network  layer  management 
information  has  been  developed  [SC6  N  6413,  December  1990].  SC6  has  developed  a  set  of 
general  principles  for  the  definition  of  lower  layer  management  [SC6  N  5784,  January  1990; 
SC21  N  4630,  April  1990].  These  principles  extend  and  refine  the  Guidelines  for  the  Definition  of 
Managed  Objects  (ISO  10165-4). 

12.1.1  Development  of  OSI  Management  Standards 

Network  management  standards  are  being  developed  by  SC21/WG4.  TSGCE  SG9 
activities  have  been  directed  at  identifying  issues  and  positions  of  concern  to  military  applications 
and  influencing  the  direction  of  the  work  in  ISGTEC.  The  emphasis  of  the  TSGCE  SG9  issues 
has  been  in  the  area  of  quality  of  service  (QoS). 
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Source:  IS0 10040,  Syttorm  Management  Overview.  SC21  N  6353, 

4  September  1981 .  Updated  October  1093. 

Figure  14.  OSI  Management  Standarde 

12.1.2  ISO  Approach  to  OSI  Management** 

OSI  Management  concerns  itself  with  three  area:  inter-system  communications  carrying 
management  information,  structure  of  the  management  information,  and  management  functions  to 
be  undertaken  by  end  systems.  There  are  three  ways  by  which  management  information  is 
communicated: 

•  Systems  Management  protocols  at  the  Application  Layer 

•  Layer  management  protocols  at  lower  layers 

•  Normal  operation  of  layer  protocols. 

Systems  Management  is  the  preferred  method.  The  others  are  required  only  because  OSI 
Management  concerns  the  resources  and  activities  needed  to  monitor  and  control  the  open 
communications  environment  They  are  not  required  for  management  outside  OSI  Management 

Systems  Management  uses  a  Common  Management  Information  Protocol  (CMIP) 
(ISO  9596)  to  communicate  information  between  systems.  This  identifies  information  to  be 
transferred  and  whether  the  transfer  concerns  an  event  report  or  an  operation.  Event  reports  are 
generated  to  notify  another  system  of  an  asynchronous  happening.  Operations  can  monitor  data 
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and  can  exercise  control  either  by  assigning  data  values  or  initiating  actions  through  a  synchronous 
communication  between  end-systems. 

12.1.2.1  Functional  Areas 

Establishing  the  scope  of  OSI  Management  is  deemed  necessary  to  establishing  a 
consensus  concerning  the  requirements.  This  led  to  identifying  five  functional  areas  for 
management:  fault  management,  configuration  management,  accounting  management, 
performance  management,  and  security  management.  Although  this  approach  had  some 
advantages  in  resolving  basic  elements  of  functionality,  it  also  exercised  a  constraining  influence 
over  the  organization  of  work.  Each  functional  area  became  concerned  with  its  narrow 
perspective.  This  led  to  questions  concerning  the  interplay  between  functional  areas,  exemplified 
by  the  following:  "How  does  one  handle  standards  for  reconfiguring  a  system  once  a  fault  has 
been  detected?" 

12.1.2.2  Focus  on  Managed  Objects 

A  clarification  came  from  a  shift  of  emphasis  to  the  data  of  concern  to  management  Only 
when  the  data  have  been  defined  are  the  functions,  which  use  the  data  throug  monitoring  or 
controlling  activities,  considered.  This  has  resulted  in  simpler  functional  standards.  Each  function 
can  now  stand  alone  rather  than  being  bound  into  a  composite  document  covering  all  the  functions 
conceived  as  belonging  to  a  particular  area.  It  also  enabled  functions  that  cross  the  preconceived 
functional  area  boundaries  to  be  handled  in  a  natural  maimer.  The  result  is  that  a  particular  function 
can  be  issued  as  a  CD  proposal  when  it  is  deemed  to  be  technically  stable  without  being  unduly 
delayed  by  less  mature  work  considered  as  belonging  to  the  same  functional  area. 

With  this  shift  of  emphasis  towards  data,  the  aim  is  now  to  identify  the  objects  of  concern 
to  management,  .heir  attributes,  and  the  operations  that  may  be  performed  upon  them.  The 
communication  services  are  thus  the  vehicles  for  carrying  the  values  of  attributes  and  a  coded  field 
identifying  the  operation  to  be  carried  out  on  a  specific  object,  not  for  carrying  information 
specifying  a  functional  area.  The  approach  is  very  close  to  (but  not  quite  identical  with)  object- 
oriented  methods.  It  has  meant  that  work  has  concentrated  on  the  management  interchanges 
between  systems  performing  a  managing  role  and  systems  operating  in  an  agent  role  manipulating 
internal  managed  objects.  There  has  been  little  investigation  of  management  exchanges  between 
peer,  managing  entities,  or  of  the  management  procedures  invoked  by  managers. 

The  object-oriented  approach  has  enabled  OSI  Management  experts,  in  collaboration  with 
those  developing  standards  for  various  OSI  layer  protocols,  to  identify  classes  of  managed  objects 
and  commonly  used  attributes.  This  in  turn  has  promoted  the  development  of  a  standard  naming 
scheme  through  which  to  identify  instances  of  object  classes.  The  naming  scheme  is  based  on  that 
used  for  Directory  services.  This  facilitates  the  use  of  directories,  conforming  to  ISO  9494  (ITU- 
TS  Recommendation  X.500),  when  management  makes  references  to  OSI  objects. 

A  March  1991  paper  entitled  Proliferation  of  Managed  Objects  [SC21  N  5756]  noted  that 
many  groups  within  ITU-TS  and  ISO  are  developing  managed  object  definitions  without  the 
benefit  of  overall  coordination.  It  suggests  that  this  problem  can  only  be  solved  by  taking  an 
overall  view  of  managed  object  definition  activities  that  requires  a  global  management  information 
authority,  capable  of  influencing  the  activities  of  at  least  all  the  standards  bodies. 

Moreover,  managed  objects  require  garbage  collection.  Garbage  collection  comprises  the 
garbage  collector  and  the  expiry  behavior.  The  purpose  of  expiry  behavior  is  to  determine  when  an 
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object  is  subject  to  garbage  collection.  SC21/WG4  [SC21/WG4  N  1381]  recently  called  for 
contributions  on  the  definition  of  expiry  behavior.  [Ref.  X3  1992b]  The  UK  and  Australian 
National  Bodies  see  no  need  for  special  mechanisms  to  handle  expiry  behavior.  A  second  WD 
Working  Document  for  Expiry  Behaviour  [SC21 N  7959,  July  1993]  has  been  circulated  to  SC21 
for  study  and  comment;  it  was  updated  by  SC21/WG4  in  December  1993  [SC21/WG4  N  1831]. 
Expiry  behavior  is  expected  to  be  added  to  the  scope  of  a  new  work  item  or  to  the  Enhanced  Event 
Control  Function  (WD  10164-ev)  (see  Section  12.1.3.1). 

12.1.2.3  Distributed  Processing  Aspects 

The  shift  of  emphasis  has  been  further  beneficial  in  bringing  into  relief  the  fact  that  some 
management  has  been  recognized  as  a  distributed  processing  activity  with  its  own  managed 
objects.  For  example,  the  "event  forwarding  discriminator"  takes  management  decisions  about 
what  should  be  done  to  asynchronous  notifications  flowing  from  OSI  managed  objects. 

Thus,  OSI  Management  standards  are  beginning  to  reveal  explicitly  what  has  always  been 
known  by  management  specialists;  i.e.,  management  is  a  distributed  processing  activity  and  has 
much  in  common  with  other  distributed  processing  activities.  Management's  distinguishing  feature 
is  that  the  scope  of  die  distributed  application  is  limited  to  manipulating  the  information  processing, 
storage,  input/output,  and  communications  environments  themselves.  Hence,  particular  attention 
is  paid  to  controlling  the  permission  to  obtain  and  act  upon  system  information. 

SC21/WG4  requested  national  body  contributions  to  progress  a  new  work  item  on 
distributed  management  for  discussion  at  a  collaborative  meeting  held  in  the  United  Kingdom  in 
December  1992.  [Ref.  SC21 N  7129  1992] 

12.1.2.4  Results  of  Work  in  OSI  Management 

OSI  Management  has  had  a  long  learning  process.  The  lessons  learned  have  been  valuable 
and  appear  to  be  applicable  to  management  in  general.  The  following  steps  are  important  in 
creating  new  management  standards: 

•  Establish  a  requirement,  since  this  sets  die  scope  for  the  standard. 

•  Identify  the  objects  of  concern  to  management  through  which  that  requirement  is 
realized.  With  identification  of  the  objects  goes  the  identification  of  their  attributes, 
operations,  and  of  any  objects  that  can  be  encapsulated  within  the  identified  objects. 

•  Establish  a  naming  scheme  for  the  objects  and  their  attributes. 

•  Identify  management  procedures  that,  through  monitoring  and  controlling  activities, 
meet  the  requirement.  Where  a  procedure  requires  inter-system  communication,  the 
communication  is  provided  through  the  use  of  CMIP. 

The  Structure  of  Management  Information  (SMI)  standards  for  OSI  set  out  rules  for 
specifying  managed  objects,  attributes,  and  their  operations.  Although  detailed  investigations 
remain  to  be  carried  out,  first  impressions  are  that  these  rules  are  applicable  to  all  aspects  of 
management  However,  it  could  be  that  further  investigation  will  reveal  places  where  detail  may 
need  to  be  refined. 

OSI  Management  standards  identify  a  number  of  attributes  that  are  common  to  many 
management  activities  (e.g.,  counters,  gauges,  thresholds,  status,  logs)  and  many  events  that  have 
general  applicability  (e.g.,  fault  reporting,  exception  handling).  Though  not  yet  as  well  developed, 
it  appears  that  OSI  management  procedures  for  testing,  accounting,  managing,  and  accessing  logs 
have  die  same  general  applicability.  Adopting  this  work  as  a  basis  and  providing  extensions  where 
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required  will  (a)  obviate  rework,  (b)  help  limit  the  unnecessary  proliferation  of  managed  standards, 
and  (c)  help  reduce  the  diversity  of  management  software  that  suppliers  have  to  write  to  support 
open  distributed  management 

In  communicating  related  sets  of  operations  to  be  performed  or  invoking  remote  operations, 
a  managing  system  may  wish  to  assert  relative  priorities  to  various  tasks.  If  and  how  priority 
should  be  handled  and  communicated  through  CMIP  is  an  open  question. 

12.1.2.5  Conformance 

SC21/WG4  has  only  begun  to  describe  how  conformance  statements  should  be  constructed 
so  that  they  apply  meaningfully  to  OSI  Management  The  one  exception  is  CMIP  for  which,  being 
a  conventional  Application  Layer  protocol,  the  task  of  generating  conformance  statements  is 
straightforward. 

The  main  problem  is  that  OSI  Management  is  concerned  not  just  with  "how”  something  is 
communicated  (CMIP)  but  "what"  is  communicated  (SMI)  and  "why"  (management  functions  and 
procedures).  Whereas  conformance  and  particularly  the  demonstration  of  conformance  through 
conformance  testing  is  readily  applied  to  CMIP  since  the  communication  is  visible  and 
monitorable,  die  "what"  and  "why"  require  that  conformance  testing  be  applied  to  activities  taking 
place  within  end  systems.  There  is  a  need  to  investigate  whether  the  approach  of  the  OSI 
Conformance  Testing  Methodology  is  applicable  or  whether  another  method  needs  to  be 
developed.  Any  method  must  recognize  the  distributed  nature  of  management  operations  and  so 
would  probably  be  appropriate  to  other  classes  of  distributed  processing  enterprise. 

An  April  1992  contribution  on  the  testability  of  managed  objects  [Ref. 
SC21/WG4  N  1438  1992]  addressed  some  of  these  issues.  Subsequently,  a  question  (Q 1/63 .2) 
on  Testability  of  Managed  Objects  was  registered.  A  draft  answer  (SC21  N  7079)  suggested  dial 
emphasis  be  given  initially  to  managed  objects  in  the  sense  of  testing  the  access  to  managed  objects 
via  CMIP  and  System  Management  Functions  in  the  context  of  Network  Management  Profiles. 
[Ref.  SC21N  7079  1992] 

Consideration  of  conformance  to  management  standards,  with  the  wider  scope  of  open 
distributed  processing,  could  have  the  beneficial  effect  of  clarifying  the  conformance  requirements, 
conformance  clauses,  PICS  proformas  (or  the  equivalent),  and  profiles  for  OSI  Management 
standards.  [Ref.  Langsford  1989] 

12.1.2.6  Security 

SC21  N  6037,  May  1991,  called  for  contributions  on  the  need  for  security  services  within 
OSI  management  It  identified  the  following  security  services: 

•  Access  control 

•  Authentication  (e.g„  peer  authentication,  data-origin  authentication) 

•  Integrity 

•  Auditing 

•  Confidentiality 

•  Non-repudiation. 

The  United  Kingdom,  in  its  response  [SC21/WG4  N  1420],  stated  that  of  these  services, 
only  the  audit  functions  were  truly  specific  to  WG4  and  that  WG4  need  not  specify  its  own 
functions  for  die  other  security  services.  It  proposed  specifying  requirements  and,  in  liaison  with 
WG1  and  WG6,  ascertaining  whether  these  requirements  can  be  satisfied  by  other  existing  or 
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emerging  standards.  Canada,  in  its  response  [SC21/WG4  N  1433],  concurred  with  the  United 
Kingdom  and  proposed  that  WG4  prepare  a  security  requirements  statement  and  establish  liaison 
with  SC6  and  SC21/WG6.  The  United  States,  in  its  response  [SC21/WG4  N  1486],  also  agreed 
that  management  of  security  services  should  be  an  integral  part  of  the  development  of  security 
services  and  suggested  assigning  priorities  to  threats  for  the  purpose  of  scheduling  the 
development  of  security  services. 

As  a  result,  in  May  1992,  SC21/WG4  issued  a  liaison  statement  to  SC21/WG1, 
SC21/WG6,  SC6,  and  SC27  on  the  security  requirements  of  OSI  systems  management  It  listed 
11  requirements,  of  which  it  classified  the  following  as  high  priority:  authentication,  access 
control,  and  auditing  and  alarm  reporting.  It  further  noted  that  alarm  reporting,  security  audit  trail 
reporting,  and  access  control  are  already  international  standards  (ISO/IEC  10164-7, 10164-8,  and 
10164-9,  respectively;  see  Section  12.1.3.1  below).  Thus,  mature  and  stable  work  to  satisfy  these 
requirements  are  already  available.  WG4  requested  comments  on  whether  [Ref.  SC21  N  7145 
1992]: 

•  There  are  current  developments  that  satisfy  some  or  all  of  the  requirements. 

•  The  priorities  are  reasonable  and  in  line  with  current  work  activities. 

•  Closer  liaison  to  describe  these  requirements  is  desirable  or  necessary. 

12.1.3  ISO  Standards  for  OSI  Management 

A  recent  survey  by  die  research  company  International  Data  Corporation  (IDC)  concluded 
that  while  users  are  cautious  about  actually  migrating  to  OSI  network  management,  they  require 
suppliers  to  commit  to  providing  it  in  the  future.  Moreover,  OSI  management  has  emerged  as  a 
possible  solution  to  users'  connectivity  requirements.  Finally,  international  networks  are  more 
focused  on  OSI  management  while  in  the  United  States  die  Simple  Network  Management  Protocol 
(SNMP)  (see  Section  12.1.9)  now  evolving  to  SMP,  has  gained  momentum  as  the  management 
protocol  of  choice  despite  its  limited  functionality.  [Ref.  OSN  1992d] 

Section  12.1.3.1  identifies  the  key  OSI  management  standards  and  summarizes  their  status. 
The  remaining  parts  of  Section  12.1.3  expand  on  the  work  of  SC21  on  these  and  related  standards 
projects. 

12.1.3.1  Identification  and  Status  of  OSI  Management  Standards 

Framework  and  Overview.  The  following  give  the  overview  and  architecture 
developed  for  OSI  management  standards: 

•  OSI  Management  Framework,  ISO  7498-4,  November  1989  (ITU-TS  X.700).  The 
Framework  document  provides  an  architectural  overview.  In  June  1993,  SC21 
proposed  confirmation  of  this  standard  with  addition  of  a  technical  corrigendum  based 
<m  the  January  1992  defect  report  [SC21 N  6658]. 

•  Systems  Management  Overview,  ISO  10040,  November  1992  (ITU-TS  X.701).  The 
Overview  document  provides  more  detailed  architectural  concepts.  It  defines  the 
architecture  for  systems  management,  which  is  management  using  Application  Layer 
protocols  for  communication,  and  it  sets  out  the  scope  of  the  other  systems 
management  standards. 

AM  1,  Management  Knowledge  Management  Architecture,  February  1993 
[SC21  N  7527] 

PDAM  2,  Management  Domains  Architecture,  November  1993  [SC21  N  7946] 
(balloting  ended  February  1994;  editing  meeting  April  1994) 
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Additional  amendment  or  technical  corrigendum  to  address  changes  to  system 
management  standards  based  on  the  final  answer  to  Q  1/49.9  on  long-term 
solution  to  general  and  dependent  conformance. 

Systems  Management  Functional  Areas  (SMFAs).  ISQ/IEC  10164,  Open 
Systems  Interconnection  -  Systems  Management,  has  been  developed  to  address  system 
management  functions.  Nearly  20  formal  standards  have  been  developed  so  far  for  Systems 
Management  Each  is  subject  to  a  technical  corrigendum  resulting  from  the  interim  WG4  meeting 
in  December  1993  and  based  on  SC21 N  7966,  which  incorporated  the  final  answer  to  Q  1/49.9  on 
die  long-term  solution  to  general  and  dependent  conformance.  Amendments  entitled  ICS  Proforma 
were  originally  entitled  MOCS/PICS  Proforma.  The  first  seven  of  these  amendments  are  expected 
to  progress  to  IS  status  (AMs)  following  conclusion  of  balloting  in  June  1994  and  the  editing 
meeting  of  July  1994;  initiation  of  ITU-TS  approval  expected  November  1994.  The  parts  of 
Systems  Management  and  their  amendments  are  as  follows: 

•  ISQ/IEC  10164-1  (Part  1):  Object  Management  Function,  June  1993  (X.730) 

-  DAM  1,  ICS  Proforma,  December  1993  [SC21  N  8240] 

•  ISQ/IEC  10164-2  (Part  2):  State  Management  Function  (ITU-TS  X.731) 

-  DAM  1,  ICS  Proforma,  December  1993  [SC21  N  8241] 

•  ISQ/IEC  10164-3  (Part  3):  Attributes  for  Representing  Relationships  (X.732) 

-  DAM  1,  ICS  Proforma,  December  1993  [SC21  N  8242] 

•  ISQ/IEC  10164-4  (Part  4):  Alarm  Reporting  Function,  December  1992  (X.733) 

-  DAM  1,  ICS  Proforma,  December  1993  [SC21  N  8243] 

•  ISQ/IEC  10164-5  (Part  5):  Event  Report  Management  Function,  June  1993  (formerly 
entitled  Management  Service  Control  Function)  (X.734) 

-  DAM  1,  ICS  Proforma,  December  1993  [SC21  N  8244] 

PDAM  2,  Enhanced  Discriminator,  August  1993  (editing  meeting  April  1994) 

•  ISO/IEC  10164-6  (Part  6):  Log  Control  Function,  November  1993  (X.735) 

-  DAM  1,  ICS  Proforma,  December  1993  [SC21  N  8245] 

PDAM  2,  Enhanced  Log,  August  1993  (editing  meeting  April  1994) 

•  ISQ/IEC  10164-7  (Part  7):  Security  Alarm  Reporting  Function,  May  1992  (X.736) 

-  DAM  1,  ICS  Proforma,  December  1993  [SC21  N  8246] 

•  ISQ/IEC  10164-8  (Part  8):  Security  Audit  Trail  Function,  June  1993  (X.740) 

•  ISQ/IEC  10164-9  (Part  9):  Objects  and  Attributes  for  Access  Control,  November 
1993  [SC21  N  7661]  (X.741)  (ballot  ended  October  1993;  editing  meeting  February 
1994;  initiation  of  ITU-TS  approval  expected  February  1994) 

•  DIS  10164-10.2  (Part  10):  Usage  Metering  Function,  November  1993  (formerly 
entitled  Accounting  Meter  Function)  [SC21  N  8238]  (X. 742)  (ballot  ended  February 
1994;  editing  meeting  April  1994;  initiation  of  ITU-TS  approval  expected  November 
1994) 

WDAM  1,  ICS  Proforma,  September  1993  (PDAM  expected  July  1994) 

•  ISO/IEC  10164-11  (Part  11):  Metric  Objects  and  Attributes,  March  1993  (formerly 
entitled  Workload  Monitoring  Function)  (X. 739). 

-  WDAM  1,  ICS  Proforma,  September  1993  [SC21  N  8162]  (PDAM  expected 
July  1994) 

WDAM  2,  Additional  Metric  Objects  and  Attributes,  September  1993 
[SC21  N  8161]  (PDAM  expected  July  1994) 

•  ISQ/IEC  10164-12  (Part  12):  Test  Management  Function,  December  1992  (X.745) 

-  PDAM  1,  ICS  Proforma,  November  1993  [SC21  N  8335] 
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•  DQQBC  10164-13  (Put  13):  Summarization  Function,  September  1993  (X.738) 

-  WDAM  1,  ICS  Proforma,  September  1993  [SC21  N  8163] 

WDAM  2,  Additional  Summarization  Scanners,  July  1993  [SC21 N  7963] 

•  DIS  10164-14.2  (Part  14):  Confidence  and  Diagnostic  Test  Categories,  May  1993 
[SC21  N  7454]  (X.737) 

•  ISCVIEC  10164-15  (Part  15):  Scheduling  Function,  April  1993  [SC21  N  7683] 
(editing  meeting  February  1994;  initiation  of  ITU-TS  approval  expected  November 
1994)  (X.746) 

•  CD  10164-16.2  (Part  16):  Management  Knowledge  Management  Function, 
October  1993  [SC21  N  8310]  (initiation  of  ITU-TS  approval  expected 
November  1994)  (X.750) 

•  CD  10164-17  (Part  17):  Change  Over  Function,  January  1994  [SC21  N  8422]  (note 
that  die  Change  Over  Function  is  similar  to,  and  possibly  a  generalization  of,  the 
Synchronous  Data  Hierarchy  Protection  Switching  Function  developed  by  ITU-TS 
SG15)  (initiation  of  ITU-TS  approval  ballot  expected  in  1997)  (X. 751) 

•  CD  10164-19  (Part  19):  Management  Domain  and  Management  Policy  Management 
Function,  January  1994  [SC21  N  8423]  (initiation  of  ITU-TS  approval  ballot 
expected  in  1997)  (X.749) 

Work  in  SC21/WG4  on  OSI  management  is  continuing  on  several  new  parts  for  Systems 
Management,  ISO  10164.  CDs  are  expected  in  1994;  initiation  of  ITU-TS  approval  expected  in 
1997. 

•  WD  10164-cs:  Command  Sequencer  for  Systems  Management,  December  1993 
[SC21  N  7962;  SC21/WG4  N  1832]] 

•  WD  10164~ev.2:  Enhanced  Event  Control  Function,  second  WD,  July  1993 
[SC21  N  7958].  This  NWI  passed  in  May  1992  and  Expiry  Behavior  (see 
Section  12.1.2.2)  was  added  to  its  scope.  [Ref.  SC21  N  7107  rev  1992] 

•  WD  10164-rm.2:  General  Relationship  Management  Function,  second  WD, 
June  1993  [SC21  N8040] 

•  WD  10164-rtm:  Response  Time  Monitoring  Function,  August  1990  [SC21  N  7970; 
JTC1N963] 

•  WD  10164-sw:  Software  Management  Function,  September  1993  [SC21  N  8201] 

•  WD  I0164-tm.2:  Time  Management :  Function  Representation  of  Time,  second  WD, 
July  1993  [SC21 N  7961] — deals  with  the  distribution  and  synchronization  of  time  in 
a  distributed  environment. 

Profiles.  The  three  regional  workshops  (AOW,  EWOS,  and  OIW)  are  currently 
developing  profiles  (DISP  12059-2,  Annex  B)  for  use  of  Systems  Management  standards 
(ISOdEC  10164-1  to  -6)  and  the  Definition  of  Management  Information  standard  (ISO  10165-2). 
[Ref.  SC21N  6915  1992] 

Liaison  and  Coordination.  Noting  overlap  between  the  scope  of  work  within 
SC21/WG4  and  SC22/WG15  (System  Administration  Interface/Software),  JTC1,  and  die  ITU-TS 
Software  Management  Subgroup  established  at  a  Collaborative  Meeting  on  Systems  Management 
in  November  1991,  that  SC21/WG4  should  be  concerned  only  with  the  management  aspects  of 
software  resources,  and  that  SC22/WG15  should  be  concerned  with  wider  aspects  such  as 
portability,  packaging,  distribution,  administration,  and  management  aspects.  JTC1  and  the  ITU- 
TS  Software  Management  Group  requested  that  an  official  liaison  be  established  between  the  two 
working  groups  to  consider  this  issue  and  agree  on  a  common  position  for  future  work  and 
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collaboration.  [Ref.  SC21  N  6664  1992]  The  work  of  WG4,  originating  from  the  IEEE  PI 003. 7b 
Software  Management  project  (see  Section  10.2.1.1)  and  WG4's  Software  Management  Function 
(WD  10164-sw)  ate  on  roughly  comparable  schedules.  The  two  groups  plan  to  continue 
cooperating  by  exchange  of  future  drafts,  with  liaison  continuing  as  the  opportunity  arises.  [Ref. 
SC21N7146  1992] 

There  is  also  substantial  overlap  between  WD  10164-tm,  Time  Management  Function 
[SC21  N  7961],  and  the  SC18/WG4  proposed  Coordinated  Time  Service  standard  (see 
Section  9.13.1). 

Structure  of  Management  Information  (SMI).  ISO/IEC  10165,  Structure  of 
Management  Information ,  has  the  following  parts  (Part  3  was  cancelled  in  November  1989  by 
recommendation  of  SC21  and  incorporated  into  Part  2): 

•  ISO/IEC  10165-1  (Part  1):  Management  Information  Model,  September  1993  (X.720) 

PD  AM  1:  Generalization  of  Terms,  June  1993  [SC21  N  7847]  (formerly  entitled 

General  Relationship  Model'  editing  meeting  February  1994) 

•  ISCVIEC  10165-2  (Part  2):  Definition  of  Management  Information,  July  1993  (X.721) 

PD  AM  1.2,  Enhanced  Discriminator  and  Log,  January  1993  [SC21 N  7559] 

•  ISO/IEC  10165-4  (Part  4):  Guidelines  for  the  Definition  of  Managed  Objects, 
September  1992  (X. 722) 

PDAM  1,  GDMO  Extensions,  July  1993  [SC21  N  7948]  (formerly  entitled 

General  Relationship  Model) 

PDAM  2,  Set  By  Create  and  Component  Registration,  1993  (editing  meeting 

February  1994) 

•  ISO/IEC  10165-5  (Part  5):  Generic  Management  Information,  March  1993  (X.734) 
(previously  entitled  Generic  Managed  Objects) 

•  ISO/IEC  10165-6  (Part  6):  Requirements  and  Guidelines  for  Implementation 
Conformance  Statement  Proformas  Associated  with  Management  Information, 
June  1993  [SC21  N  7894]  (X.724) 

WDAM  1,  Manager  Role  Conformance  [SC21  N  7964,  July  1993] 

•  CD  10165-7.2  (Part  7):  General  Relationship  Model,  September  1993  [SC21 N  8036] 
(X.725)  (formerly  entitled  Management  Information  Register  (MIR)  and  Registration 
Procedure). 

Management  Information  in  the  Upper  Layers.  A  WD  has  been  developed  on 
Managed  Objects  in  die  Upper  Layers,  June  1993  [SC21  N  8178].  Work  on  this  document  was 
transferred  in  June  1993  from  SC21/WG8  to  SC21/WG4.  CD  status  is  expected  July  1994.  The 
document  establishes  a  model  for  common  upper  layer  objects,  gives  an  overview  of  the 
definitions  imported  from  the  Generic  Management  Information  (ISO/IEC  10165-5),  and  provides 
generic  and  formal  definitions  for  common  upper  layer  information  (managed  objects).  The  model 
for  managed  objects  includes  a  naming  tree,  basic  building  blocks,  extended  application  layer 
structure  (XALS)  recursive  model,  provision  for  separable  upper  layers,  and  provision  for  a 
monolithic  upper  layer  entity. 

System  Management  Communications.  Standards  have  been  defined  to  specify 
services  and  protocols  for  exchanging  management  information.  They  are  the  collaborative  effort 
of  ISO/IEC  and  ITU-TS.  The  system  management  communications  standards  are  the  following: 

•  ISCVIEC  9595: 1991,  Common  Management  Information  Service  ( CMIS)  Definition, 
Edition  2  (incorporates  AM  1  and  AM  2),  April  1991  (X.710).  CMIS  defines 
services  for  acting  on  an  object  and  includes  creation  and  deletion.  Services  can  apply 
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to  values  from  a  set  of  attribute  values;  die  attribute  values  can  have  the  structure  of  a 
table,  so  that  services  can  affect  entries,  entire  rows,  and  entire  columns. 
Amendments  are  die  following: 

PD  AM  3,  Support  of  Allomorphism,6'7  November  1990 — project  was  cancelled 
by  JTC1  on  the  recommendation  of  SC21  in  May  1992 
AM  4,  Access  Control,  July  1992 — addresses  the  use  of  the  access  control  field 
WDAM  3,  Enhanced  Functionality  for  System  Management  Communications, 
June  1993  [SC21  N  7970];  PD  AM  expected  December  1994. 

•  ISO/IEC  9596-1:1991,  Common  Management  Information  Protocol  (CMIP),  Part  1: 
Specification,  Edition  2  (incorporates  AM  1  and  AM  2),  June  1991  (X.711).  CMIP 
defines  peer  protocols  for  layer  services  between  Systems  Management  entities. 
Amendments  are  the  following: 

PDAM  3,  Support  of  Allomorphism,  July  1990 — project  was  cancelled  by  JTC1 
on  die  recommendation  of  SC21  in  May  1992 
-  PDAM  4,  State  Tables  for  CMIP,  January  1990  [SC21  N  4058]— project 
cancelled  June  1991). 

WDAM  5,  Enhanced  Functionality,  June  1993  [SC21  N  7970],  PDAM  expected 
December  1994. 

•  ISO/IEC  9596-2:1991,  Common  Management  Information  Protocol  (CMIP),  Part  2: 
PICS  Proforma,  June  1993  (X.712). 

Other  OSI  Management  Standards.  Other  OSI  management  standards  are  as  follows: 

•  ISO/IEC  10733,  Telecommunications  and  Information  Exchange  Between  Systems  - 
Elements  of  Management  Information  Related  to  OSI  Network  Layer  Standards ,  1993. 

•  ISO/IEC  10737,  Specification  of  the  Elements  of  Management  Information  Related  to 
OSI  Transport  Layer  Standards,  1993.  A  liaison  statement  from  SC6/WG4  to  the 
ULA  group  cited  ISO/IEC  10737  as  an  example  of  a  layer  management  specification. 
SC6/WG4's  examination  of  ISO/IEC  10737  discovered  two  problems  with  the 
managed-object  structure  described  in  the  document  that  seem  to  contradict  the 
Reference  Model  [Ref.  SC21  N  6606  1991] 

•  CD  11587.2,  Application  Context  for  Systems  Management  with  TP,  July  1993 
[SC21  N  7899]  (editing  meeting  February  1994;  initiation  of  ITU-TS  approval 
expected  June  1995)  (X. 702) 

Management  Issues,  hi  response  to  a  request  for  NB  comments  on  the  progression  of 
an  Amendment  to  ISO  10164-11  on  the  Definition  of  Multiple  Input  Metric  Objects,  the  United 
States  submitted  a  document  on  a  Method  for  Comparing  Counters  to  Set  Threshold  Levels  for 
Generating  Notifications.  If  accepted,  the  United  States  intends  to  provide  further  enhancements 
that  will  provide  further  basis  for  the  amendment  [Ref.  SC21  WG4  N 1472  1991]  A  Preliminary 
Document  on  Multiple  Input  Metric  Objects  [SC21  N  7134]  was  proposed  in  May  1992.  The 
Performance  Management  Group  proposes  progressing  it  as  an  amendment  to  the  workload 
monitoring  function  (ISO  10164-11).  [Ref.  SC21  N  7134  1992]  The  items  to  be  considered  for 
this  addendum  include: 

•  A  Metric  Managed  Object  (or  set  of  metric  objects)  that  would  provide  die  identifier  of 
the  algorithm  used  to  calculate  the  metric 


67  Aa  object  in  a  refined  darn  (Le.,  a  subclass)  of  a  class  definition  (e.g.,  a  modem)  conkl  behave  in  certain 
shuaflont  as  if  it  were  the  parent  This  characteristic,  called  polymorphism  or  more  recently  allomorphism, 
would  support  backwards  compatibility.  The  way  in  which  aa  object  would  respond  would  depend  on  bow  it  is 
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•  A  set  of  Multiple  Input  Metric  Object  Classes 

•  A  new  algorithm  for  the  calculation  of  percentiles  (Exponentially  Weighted  Stochastic 
Approximation  (EWSA))  that  will  provide  a  higher  degree  of  accuracy  at  the  tails  of 
die  distribution  than  the  EWMA  percentile  algorithm  currently  defined  in  10164-11. 

The  December  1992  editing  meeting  also  agreed  that  the  ICS  for  ISO  10164-1 1  should  be 
progressed  as  an  addendum,  but  separately  from  the  items  listed  above.  [Ref.  SC21  N  7S3S  1993] 
The  ICS  requirements  for  10164-11  are  detailed  in  [Ref.  SC21  N  7534  1993]. 

One  of  the  major  issues  raised  at  the  Test  Management  Function  (ISO  10164-12)  editing 
meeting  in  October  1991  was  a  proposal  to  incorporate  the  concept  that  a  managing  system  may 
request  that  a  test  be  run  with  a  given  priority.  The  requirement  was  accepted,  but  it  was 
considered  by  the  majority  of  the  meeting  that  prioritization  was  a  general  requirement  and  should 
be  progressed  as  such.  Tire  editing  group  requested  that  the  Common  Management  Working 
Group  consider  prioritization  as  a  work  item.  [Ref.  SC21  N  6559  1991] 

In  support  of  the  Telecommunication  Management  Network  (TMN)  development  (see 
Section  12.1.4),  ITU-TS  SG  XI  is  developing  a  model  for  performance  monitoring  to  be 
documented  in  Draft  Recommendation  Q.82pm,  Stage  2  and  Stage  3  Description  for  the  Q3 
Interface  -  Performance  Management.  This  model  uses  the  functionality  defined  in  ISO  10164-13 
for  the  object  classes  Scanner,  homogeneous  Scanner,  Simple  Scanner,  and  scanReportRecord. 
Thus,  ITU-TS  recommends  keeping  this  functionality  as  currently  documented  in  ISO  10164-13. 
In  addition,  drey  would  like  to  add  to  the  behavior  of  the  Scanner  object  class  the  capability  to  scan 
itself.  [Ref.  SC21  N  6896  1992] 

In  November  1990,  it  was  agreed  that  after  Version  2  of  CMIS  and  CMIP  there  will  be  no 
further  releases  (either  in  the  form  of  addenda  or  completed  standards)  that  could  affect 
interoperability  before  1994  [Ref.  SC21 N  5546  1990].  Therefore,  in  nominating  solutions  for  the 
NWI  on  Enhanced  Functionality  for  Systems  Management  Communications,  National  Bodies  were 
asked  to  consider  solutions  that  do  not  require  enhancements  to  CMIS/CMIP. 

In  a  liaison  statement  to  SC21/WG4,  ITU-TS  SG  VII  state  that  the  enhancement  to 
CMIS/CMIP  (see  Section  12.1.3.2)  on  transaction  processing  capability  for  ITU-TS  applications 
is  an  important  work  item  in  the  next  study  period  in  ITU-TS  SG  VII  Q.24.  An  attached  document 
brings  up  several  requirements  that  could  be  satisfied  by  new  work  on  atomic  transaction  support 
[Ref.  SC21  N  6892  1992] 

Moreover,  in  a  joint  meeting  of  WG1  and  WG4  of  SC21  on  the  Draft  Technical 
Corrigendum  (TC)  to  ISO  9596-1  in  Ottawa  in  May  1992,  it  was  agreed  to  deprecate  die  use  of  die 
concept  of  general  and  dependent  conformances;  due  to  incompleteness  of  its  development  Thus, 
the  Draft  TC  was  amended  so  that  the  concept  of  general  and  dependent  conformance  classes  was 
removed  and  replaced  by  concise  statements  concerning  what  claims  to  conform  to  CMIP  may  be 
made.  The  revised  text  was  submitted  to  the  ISO  Central  Secretariat  for  publication.  However, 
ITU-TS  SG  VII  disagrees  ami  believes  die  concept  of  dependent  conformance  (i.e.,  allowing 
referencing  standards  to  use  a  subset  of  CMIS  services,  and  to  have  their  conformance  claims 
requiring  conformance  only  to  the  relevant  CMIP  protocol  elements  associated  with  the  services 
used)  is  stable  and  plans  to  publish  its  approved  text  without  those  changes.  [Ref.  SC21  N  6894 
1992]  In  May  1992  WG1  proposed  a  new  subquestion  (Ql/49.9)  on  long-term  solution  to  general 
and  dependent  conformance.  The  draft  answer  [Ref.  SC21 N  7069  1992]  states  that  the  concept  of 
general  conformance  is  misleading  and  should  be  avoided.  Moreover,  the  concept  of  dependent 
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conformance  is  not  needed,  since  it  was  introduced  to  contrast  with  general  conformance. 
Therefore,  conformance  to  s  protocol  should  be  expressed  without  use  of  either  term.  A  final 
answer  was  expected  in  May  1993.  [Ref.  SC21  N  7073  1992]  PDAMs  to  SM  Overview 
(ISO  10040)  and  the  SM  Function  standards  (ISO  10164)  on  General  and  Dependent 
Conformance  are  expected  in  December  1993. 

12.1.3.2  New  Work  Items 

New  work  items  include: 

•  Systems  Management  Tutorial,  May  1992  [SC21/WG4  N  1532]  (planned  to  be  a 
new  technical  report)  (ITU-TS  X.702).  Second  WD.  CD  provisionally  expected 
December  1993.  Several  issues  still  need  to  be  resolved,  however.  For  example, 
agreement  is  needed  as  to  the  target  audience  and  purpose.  The  SC21  Programme  of 
Work  [SC21  N  7205,  September  1992]  requested  JTC1  endorsement  to  cancel  the 
project 

•  Extended  Systems  Management  Architecture,  July  1993  [SC21  N  7957]  describes  the 
requirements  for  the  extended  systems  management  architecture.  It  is  for  further  study 
whether  this  will  be  a  separate  standard  (that  might  replace  the  current  Systems 
Management  Overview),  or  this  will  be  an  addendum  to  the  current  Systems 
Management  Overview  (ISO  10040)  At  the  Collaborative  Meeting  of  ITU-TS  Q24/VII 
and  ISO/IEC  JTC1/SC21  WG4  SM  Rapporteur  Groups  in  December  1992,  it  was 
decided  to  use  a  WG4  Standing  Document  as  a  vehicle  to  maintain  a  list  of  issues  for 
Extended  Systems  Management  Architecture.  The  issues  in  the  current  SD  (WG4 
SD1)  [Ref.  SC21 WG4  N  1641  1992]  are: 

Communication  support  for  distribution 

Naming  in  the  Extended  Systems  Management  Architecture 

Scoping  and  filtering  in  multi-system  environment 

Recursive  domains 

Visibility  of  managed  objects 

Naming  schema  objects 

Definition  of  managed  objects  for  systems  management  protocol  machines.  A 
WD  Definition  of  System  Management  Protocol  Machine  Managed  Objects 
[SC21 N  7965]  was  produced  in  September  1993. 

•  Formal  Descriptions  ofCMJP,  July  1990  [SC21  N  4947]. 

•  Managed  Object  Conformance  Statement  (MOCS)  Proformas,  February  1991 
[SC21  N  5686] — to  provide  requirements  and  develop  a  standard  specification 
technique  (template)  for  MOCS  proforma,  thus  helping  to  ensure  their  completeness, 
consistency,  and  ease  of  use.  MOCS  proformas  are  analogous  to  PICS  proformas, 
but  apply  to  managed  object  definitions  as  opposed  to  protocols. 

•  Management  Information  for  the  OSI  Upper  Layers  [SC21  N  4108]  (approved  by 
JTC1  in  May  1990).  In  May  1991,  SC21/WG6  issued  a  request  for  comment  on 
requirements  for  this  NWI  [Ref.  SC 21  N  6067  1991].  Only  the  United  States 
responded,  and,  while  the  ULA  group  felt  that  the  response  [SC21  N  6799] 
represented  good  initial  work  on  die  topic  and  posed  interesting  questions,  it  also  felt 
that  this  work  cannot  be  progressed  without  more  NB  participation.  Accordingly,  it 
urgently  requested  comments  on  the  US  contribution  [Ref.  SC21  N  6968  1992]. 
Some  issues  that  the  US  contribution  highlighted  include: 

Defining  recursion  through  relationship  attributes  in  managed  objects  flex’  XALS 
to  correspond  with  die  recursion  of  XALS  objects 

Identifying  advantages  and  disadvantages  of  alternative  definitions  of  managed 
object  classes  to  represent  the  resources  in  the  upper  layers 
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Using  the  management  domain  concept  to  differentiate  between  managed  objects 
for  different  applications 

Distinguishing  between  application  management  vs.  application  layer  management 
Clarifying  what  is  meant  by  information  for  "autonomous  management  of  the 
open  system"  in  ISO  7498-4  as  information  that  is  stored  in  the  management 
information  base. 

This  project  has  been  transferred  from  WG  8  to  WG  4.  A  related  document.  Working 

Document  on  Managed  Objects  for  Upper  Layers,  is  SC21  N  8178,  dated 

August  1993. 

In  April  1992,  SC18/WG4  circulated  a  proposal  for  a  NWI  on  Mapping  of  the  OS1  System 
Management  -  Object  Management  Function  onto  Message  Oriented  Text  Interchange  System 
(MOTIS).  The  work  is  to  define  a  new  standard  in  order  to  enable  management  information  to  be 
earned  over  MOTIS.  In  addition,  an  addendum  to  ISO  10164-1  would  be  produced.  Annexes  B 
(MHS  Model),  C  ( Mapping  Between  PT-Service  and  MHS  MTS-Service),  and  D  ( X-Protocol 
Specification )  of  ITU-TS  Draft  Recommendation  X.cnms,  Definition  of  Customer  Network 
Management  Services  for  Public  Data  Networks,  are  also  relevant  WD  status  was  expected  in 
June  1993,  CD  in  November  1993,  DIS  in  June  1994,  and  IS  in  June  1995.  [Ref.  SC21  N  7483 
1992] 

A  Collaborative  Meeting  of  ITU-TS  Q24/VII  and  ISO/IEC  JTC1/SC21  WG4  SM 
Rapporteur  Groups  in  December  1992  made  the  following  recommendations  [Ref.  SC21 
WG4  N  1615  1992]: 

•  That  a  standard  for  managed  objects  for  the  application  layer  be  developed 

•  That  an  Implementor’s  Guide  be  produced  and  maintained  to  record  defect  progress 

and  resulting  textual  changes  to  standards. 

After  reviewing  the  NB  comments  on  a  call  for  comments  on  requirements  for  support  for 
complex  attribute  types,  the  SMI  Rapporteur  Group  concluded  that  a  requirement  had  been 
established  for  the  support  of  set-valued  attributes  to  model  table  structures.  Accordingly,  WG4 
produced  a  Working  Document  on  Complex  Attribute  Types.  [SC21  N  7116,  July  1992] 
However,  Australia  contends  that  complex  attributes  can  be  represented  using  the  current  OSI 
information  modelling  tools.  [Ref.  SC21 N  7 1 16  1992] 

An  NP  for  Command  Sequencer  for  Systems  Management  [JTC1  N  2246]  has  been 
accepted  into  the  JTC  1  program  of  work,  but  SC21  has  been  requested  to  respond  to  comments 
received.  SC21  N  7962,  dated  July  1993  is  the  Working  Draft  for  this  new  work  item.  As  noted, 
it  is  expected  to  become  a  new  part  of  ISO/IEC  10164. 

The  general  requirements  of  a  NWI  entitled,  Enhanced  Functionality  for  Systems 
Management  Communications  are  [Ref.  SC21 N  7728  1993]: 

•  Bulk  data  transfer 

•  Complex  attributes 

•  Management  associations  -  quality  of  service 

•  Object  selection 

•  Synchronization 

•  Protocol  operational  behavior 

•  Deadlocks. 

Tire  WD  is  SC21  N  7970.  Target  dates  for  the  project  were  CD  in  May  1993,  DIS  in  December 
1993,  and  IS  in  August  1994.  [Ref.  SC21  N  7105  1992] 
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WG4  has  proposed  several  new  work  items  that  have  not  yet  been  officially  assigned  [Ref. 
SC21N  7630 1993]: 

•  CMIP  Machine  Managed  Object  [SC21/WG4  N 1643] 

•  Management  Information  Model  Extension  [SC21/WG4  N 1633;  SC21/WG4  N 1638] 

•  Manager  Role  Conformance,  December  1993  [SC21/WG4  N  1853] 

•  Extended  Scanners  [SC21  N  7134;  S21  N  7223] 

•  Management  Information  Library  [SC21  N  7132]. 

SC21/WG4  has  develop  a  document.  Requirements  and  Directions  for  die  Use  of  Formal 
Description  Techniques  for  the  Specification  of  Managed  Objects,  October  1993  [SC21  N  8280]. 
The  document  addresses  the  need  to  use  formal  techniques  rather  than  plain  language  descriptions, 
model-based  approaches,  object-oriented  paradigm,  life-cycle  requirements,  migration,  and 
possible  replacement  (as  a  long-term  goal)  of  the  GDMO  with  an  alternative  FDT.  Review  of 
FDTs  focuses  on  SDL  and  Z,  with  some  preference  for  SDL. 

SC21/WG4  has  a  standing  document  (SD-1)  on  Issues  for  Extended  Systems  Management 
Architecture,  July  1993  [SC21  N  7955  Revised],  which  identifies  issues  to  be  relevant  for  the 
extended  architecture  for  systems  management  ITU-TS  SG7  has  issued  and  maintains  the  OSI 
Systems  Management  Implementors  Guide,  Vernon  1,  July  1993  [SC21  N  8281],  which  records 
known  defects  in  network  management  standards:  ITU-T  X.700- Series  Recommendations, 
ISOffEC  9595, 95%.  10040, 10164,  and  10165. 

12.1.3.3  Systems  Management,  ISO  10164 

Standards.  ISO  10164,  Systems  Management,  establishes  user  requirements  for  each 
management  function,  establishes  a  model  that  relates  the  services  and  generic  definitions  provided 
by  this  function  to  user  requirements,  defines  the  services  provided,  defines  generic  notification 
types  and  parameters  documented  in  accordance  with  die  guidelines  for  the  definition  of  managed 
objects,  specifies  the  protocol  necessary  to  provide  the  service,  specifies  the  abstract  syntax 
necessary  to  identify  and  negotiate  the  functional  units  in  the  protocol  (if  necessary),  defines  the 
relationship  between  the  services  and  systems  management  operations  and  notifications,  specifies 
compliance  requirements  placed  on  other  standards  that  make  use  of  these  generic  definitions, 
defines  relationships  with  other  systems  management  functions,  and  specifies  conformance 
requirements.  ISO  10164  does  not  define  implementation  aspects,  specify  the  manner  in  which 
management  is  accomplished,  define  interactions  that  result  in  the  use  of  management  functions, 
specify  services  for  establishment  and  normal  or  abnormal  release  of  a  management  association,  or 
define  managed  objects.  The  major  management  functions  addressed  in  systems  management  are 
defined  in  Table  36. 

ISO  10164  defines  particular  systems  management  functions  and  how  these  are  achieved 
by  use  of  CMIS  ASN.l  is  the  notation  used  to  express  the  abstract  syntax  of  the  data  elements 
associated  with  managed  object,  attribute,  event,  and  action  definitions  that  shall  be  carried  in 
CMIP. 

Issues.  The  following  technical  issues  are  not  yet  addressed  by  ISO  10164  (Ref. 
SC21/WG4  1989]: 

•  Renaming  managed  objects — requirements  for  renaming  managed  objects,  including 
classes  to  be  renamed,  conditions  under  which  rename  would  be  permitted,  constraints 
on  renaming  objects  in  standardized  procedures,  and  changes  that  need  to  be 
coordinated  to  make  a  renaming  operation  consistent  and  meaningful. 
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•  Service  access  control — mechanism  to  address  the  need  for  individual  open  systems  to 
have  the  option  of  protecting  themselves  against  the  invocation  of  services  that  would 
forcibly  change  existing  configured  relationships  among  managed  objects. 

•  Startup  and  shutdown — addressing  the  requirement  to  manage  the  state  of  an  object  as 
regards  invoking  startup  (or  initialization)  and  shutdown. 

Table  36.  Definitions  of  OSI  Systems  Management  Functions 

•  555  control — Dfovidaa  consistent  levels  of  granularity  necessary  to  a  homogeneous  control  policy, 
preventing  management  notifications  from  being  sent  to  unauthorized  recipients,  preventing  initiators  from 
having  access  to  management  operations,  and  protecting  management  information  from  unintended 
disclosure.  Various  leveis  of  access  control  wiN  be  supported:  some  users  may  be  given  read  and  write 
access  to  specific  attributes  while  other  users  have  only  read  access  or  no  access;  some  users  may  be 
granted  access  only  to  specific  managed  objects;  and  some  users  may  not  be  allowed  to  establish 
management  communications  at  al. 

•  Alarm  reporting  function— reports  alarms,  errors,  and  related  information.  Malfunctions  will  range  in  severity 
from  minor,  where  a  minimal  impact  upon  the  quality  of  service  to  the  user  occurs,  to  major,  where  it  is  no 
longer  possfcle  to  provide  the  quality  of  service  requested  (or  promised  to)  the  service  user. 

•  Event  report  management— the  ability  to  specify  conditions  to  be  satisfied  by  a  potential  event  report  relating 
to  a  particular  managed  object  or  a  set  of  managed  objects,  in  order  to  be  sent  to  specified  destinations. 

•  Log  control — the  ability  to  preserve  information  about  events  that  may  have  occurred  or  operations  that  may 
have  been  performed  by  or  on  various  objects. 

•  Object  management— ability  to  create,  delete,  examine,  and  change  sets  of  management  information  that 
describe  parts  of  the  OSI  environment. 

•  Relationship  management— the  ability  to  examine  the  relationships  among  various  parts  of  the  system,  to 
see  how  the  operation  of  one  part  of  the  system  depends  upon  is  depended  upon  by  other  parts. 

•  Security  alarm  reporting  function — provides  such  capabilities  as  the  means  to  receive  notifications  of 
security-related  events,  alerts  of  any  misoperations  in  security  services  and  mechanisms,  alerts  of  attacks 
on  system  security,  and  information  as  to  the  perceived  severity  of  any  misoperation,  attack,  or  breach  of 
security.  The  standard  provides  notifications  that  include  reporting  of  fire  clearance  of  fault  conditions. 

•  Security  auefit  trail — the  ability  to  maintain  a  record  of  security-related  events  that  occur  in  the  management 
domain  and  to  review  and  analyze  these  events  to  detect  security  breaches,  malfunctions,  and 
effectiveness  of  the  security  services  and  mechanisms  that  are  implemented  pursuant  to  the  security  policy. 

•  State  management— the  ability  to  examine  and  be  notified  of  changes  in  state,  to  monitor  overall  operability 
and  usage  of  objects  in  a  consistent  manner,  and  to  give  or  withhold  permission  for  the  use  of  specific 
objects. 

•  Summarization  function— measures  throughput,  time  delays,  message  round  trips,  response  times,  and 
other  measures  of  congestion  and  resource  utilization  for  performance  monitoring  and  statistics  calculated 
across  managed  objects,  not  over  time  (see  Workload  Monitoring  Function). 

•  Teat  management  function— remote  control  of  tests  involving  real  open  systems  and  the  specification  of 
tests  that  exercise  OSI  resources. 

•  Workload  monitoring  function — may  be  used  by  an  application  process  in  a  centralized  or  decentralized 
management  environment  to  interact  to  satisfy  such  requirements  as: 

Definition  of  statistical  monitoring  tods  to  derive  metrics  to  characterize  performance 
Definition  of  a  monitoring  function  that  provides  metrics  of  the  workload,  workload  rejected,  and 
resources  used 

Specification  of  mechanisms  to  obtain  these  metrics 

Specification  of  notification*  to  be  generated  when  these  metrics  exceed  threshold  values,  and  the 
adttyto  include  addftionaJ  performance  information  into  these  notifications 
Specification  of  mechanisms  to  control  the  operation  of  this  function,  for  example  to  initiate  and  to 
terminate  monitoring 

Scheduing  of  metric  monlorioq  over  a  specified  period  of  time. 

Source:  IS0 10164-1,  June  1093. 

Specific  concerns  regarding  ISO/IEC  10164-9,  Objects  and  Attributes  for  Access  Control, 
are  that  die  document  is  technically  flawed,  the  technology  in  the  document  is  already  obsolete,  and 
the  document  contents  are  inconsistent  with  its  scope.  Moreover,  Part  9  needs  alignment  with  the 
Access  Control  Framework,  DIS  10181-3.  [Ref.  X3  1991j] 
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A  working  draft  on  Change  Over  Function  was  prepared  in  June  1992.  It  defines  services 
for  managing  backup  relationships  and  specifies  a  set  of  associated  generic  definitions.  Liaison 
between  SC21/WG4  and  ITU-TS  SG15  has  been  initiated  to  determine  die  possible  overlap  of  the 
Change  Over  Function  and  the  Synchronous  Data  Hierarchy  (SDH)  protection  switching  model. 
[Ref.  SC21N  7980  1993] 

12.1.3.4  Structure  of  Management  Information  (SMI)  (ISO  10165) 

The  Structure  of  Management  Information  (SMI)  now  has  seven  parts.  The  purpose  of 
ISO  10165-1,  Management  Information  Model,  is  to  give  structure  to  the  management  information 
conveyed  externally  by  systems  management  protocols  and  to  model  management  aspects  of  the 
related  resources  (e.g.,  an  X.25  protocol  machine).  Managed  objects  are  abstractions  of  data 
processing  and  data  communications  resources  (e.g.,  protocol  state  machines,  connections, 
modems)  for  the  purposed  of  management  It  is  the  attributes,  operations,  and  notifications  of 
managed  objects  that  are  visible  to  management  whereas  the  internal  functioning  of  the  managed 
object  (i.e.,  the  resource  it  represents)  is  not  otherwise  visible  to  management  ISO  10165-1 
describes  the  model  of  management  information  in  terms  of  managed  objects  and  the  set  of 
operations  that  may  be  performed  upon  them  and  notifications  that  they  may  generate.  It  also 
defines,  using  object-oriented  principles,  key  concepts  such  as  inheritance,  allomorphism, 
containment  and  naming  as  they  relate  to  managed  objects. 

ISO  10165-2  defines  the  generic  object  classes,  support  managed  object  classes,  abstract 
attribute  types,  attributes  types,  notifications  types,  action  types,  parameter  types,  and  associated 
abstract  syntaxes  that  may  be  applicable  to  a  number  of  different  standards.  It  also  specifies 
compliance  requirements  placed  on  other  standards  that  make  use  of  these  definitions. 

ISO  10165-4  defines  the  management  information  that  is  to  be  transferred  or  manipulated 
by  means  of  the  OSI  management  protocol  and  the  managed  objects  to  which  that  information 
relates.  ISO  10165-4  provides  developers  of  managed  object  class  definitions  with  the  information 
and  documentation  tools  that  are  required  in  order  to  produce  complete  managed  object  class 
definitions.  An  amendment  to  this  standard  is  being  proposed  to  align  it  with  10165-1  by  adding 
the  ability  to  specify  an  explicit  value  for  individual  attributes.  [Ref.  SC21 WG4  N  1640  1992] 

EO 10165-5,  Generic  Management  Information,  provides  developers  of  OSI  specifications 
that  contain  managed  object  definitions  with  generic  definitions  of  managed  object  classes  that  will: 

•  Provide  common  superclass  definitions  from  which  layer-  or  resource-specific  object 
class  definitions  may  be  derived 

•  Assist  with  the  development  of  common  elements  of  object  class  definitions  across 
multiple  layers  or  components  of  layers 

•  Reduce  duplication  of  effort  in  other  woridng  groups  by  identifying  commonly  useful 
definitions. 

In  May  1992,  at  the  SC21AVG4  SMI  Rapporteur  Group  meeting,  it  was  agreed  to  restrict 
the  scope  of  ISO  10165-6,  Requirements  and  Guidelines  for  Implementation  Conformance 
Statement  (ICS)  Proformas  to  standards  for  management  information.  This  decision  effectively 
restricts  management  conformance  proformas  to  apply  to  managed  systems.  In  agreeing  to  this 
restriction,  a  number  of  NBs  urged  that  attention  be  given  to  developing  conformance  proformas 
for  managing  systems.  In  July  1992,  WG4  requested  NB  input  on  principles  for  conformance  for 
managing  systems.  [Ref.  SC21  N  7117  1992]  NB  contributions  are  contained  in  [Ref. 
SC21/WG1  N  1233  1993]. 
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CD  10165-7.2,  General  Relationship  Model  (formerly  entitled  Management  Information 
Register  (MIR)),  is  in  a  second  CD  ballot  as  SC21  N  8036,  September  1993. 

In  a  liaison  statement  [Ref.  SC21 N  7588  1993]  to  ITU-TS  Q24/VII  concerning  Q24/VH’s 
intention  to  choose  a  formal  description  technique  (FDT)  for  the  specification  of  managed-object 
behavior,  the  SMI  Rapporteur  Group  of  SC21/WG4  highlighted  two  related  ISO  activities: 

•  SC22  proposal  to  standardize  the  FDT  Z  [JTC1  N  2159] 

•  Work  in  the  area  of  architectural  semantics  being  progressed  by  SC21/WG7  and  their 
comparison  and  analysis  of  various  FDTs  including  LOTOS,  ESTELLE,  SDL,  and  Z 
(see  Section  12.2.3). 

%2. 1.3.5  OSI  Management  Profiles 

The  following  are  ISPs  for  OSI  management  (a  complete  list  of  all  the  parts  is  provided  in 
Appendix  E): 

•  DISP  12059,  Management  Functions  -  Common  Information  for  Management 
Functions  (Parts  0-6),  1992 

•  DISP  12060,  ISPs  AOM  nnn  -  OSI  Management  -  Management  Functions  (9  parts), 
1992. 

The  EWOS  Expert  Group  on  Network  Management  (EG-NM)  has  developed  Guidelines 
for  Managed  Object  Taxonomy  and  Profiles,  Draft  3,  July  1993  [EWOS/TA/93/239].  The  EWOS 
EG-NM  has  also  developed  a  taxonomy  for  future  profiles  [SGFS  N  1076;  EWOS/T A/93/327], 
December  1993.  A  summary  of  this  taxonomy  is  provided  in  Table  37. 

12.1.4  Telecommunication  Management  Network  (TMN) 

The  Telecommunication  Management  Network  (TMN)  is  a  concept  developed  by  ITU-TS 
(Recommendation  M.30)  to  manage  a  telecommunication  network  (e.g.,  the  public  telephone 
network  or  an  ISDN).  A  TMN  is  conceptually  a  separate  network  that  interfaces  a 
telecommunications  network  at  several  different  points  to  receive  information  from  it  and  to  control 
its  operations.  A  TMN  may  use  parts  of  the  telecommunications  network  to  provide  for  its  own 
communications. 

Architecturally,  the  TMN  functions  are  divided  into  three  blocks: 

•  Operation  System  Function  (OSF)  that  processes  the  information  related  to 
telecommunication  management  to  support  or  control  the  realization  of  various 
telecommunication  management  functions. 

•  Mediation  Function  (MF)  that  acts  on  information  passing  between  Network  Element 
Functions  (see  below)  and  OSFs  to  achieve  smooth  and  efficient  communication.  The 
main  MFs  are  communication  control,  protocol  conversion,  data  handling, 
communication  of  primitives,  processing  involving  decision  making,  and  data  storage. 

•  Data  Communication  Function  (DCF)  that  provides  the  means  to  transport  information 
related  to  telecommunication  management  between  functional  blocks. 

The  three  functional  blocks  can  communicate  with  two  external  blocks.  One  is  the 
Network  Element  Function  (NEF)  that  communicates  with  a  TMN  for  the  purpose  of  being 
monitored  and/or  controlled.  The  other  is  the  Workstation  Function  (WSF)  that  provides  the 
means  for  communications  between  function  blocks  (OSF,  MF,  DCF,  and  NEF)  and  the  user. 
The  current  draft  of  the  NATO  C3  Architecture  Communications  Subsystem  (July  1989)  indicates 
that  the  management  of  the  NATO  ISDN  (see  Section  17.3.6)  will  be  based  on  the  TMN  concept 
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(Ref.  Man  1990]  The  NATO  Tactical  Communications  Architecture  (see  Section  18.1.3)  proposed 
by  TSGCE  SG11/PG6  is  also  based  on  TMN. 

Table  37.  Proposed  Taxonomy  for  OSI  Management  Profiles 


ASM  OSI  Management 

AOM  1  Management  Communications 
AOM  2  Management  Functions 

AOM  20  Super  Combinations  (for  further  study) 

AOM  2t  Management  Capabilities 

AOM  21 1  General  Management  Capability  (DISP  12060-1 ) 

AOM  212  State  and  Alarm  Management  (DISP  12060-2) 

AOM  213  Alarm  Management  (DISP  12060-3) 

AOM  22  Event  Report  Control 

AOM  221  General  Event  Control  (DISP  12060-4) 

AOM  23  Log  Control 

AOM  231  General  Log  Control  (DISP  1 2060-5) 

AOM  24  Security  (DISP  12060-x) 

AOM  241  General  Security  Capability 
AOM  242  Security  Alarms 
AOM  243  Audit  Trail 
AOM  244  Access  Control 

AOM  2441  General  Access  Control 
AOM  2442  Item  Rules  -  Access  Control  List 
AOM  2443  Rem  Rules  -  Security  Labels 
AOM  2444  Rem  Rules  -  Capability  List 
AOM  2445  Global  Rules  •  Access  Control  List 
AOM  2446  Global  Rules  -  Security  Labels 
AOM  2447  Global  Rules  -  Capability  List 
AOM  25  Performance 

AOM  251  General  Performance  (pDISP  12060-x) 

AOM  252  Metric  Objects  (pDISP  12060-y) 

AOM  2521  Monitor  Metric  Capabflity 

AOM  25211  General  Metric  Objects 
AOM  2522  Monitor  Metric  Object 
AOM  2523  Mean  Monitor  Metric  Object 
AOM  2524  Algorithm  Indicating  Mean  Monitor  Metric  Object 
AOM  2525  Moving  Average  Mean  Monitor  Metric  Object 
AOM  2526  Mean  and  Variance  Monitor  Metric  Object 
AOM  2527  Mean  and  Percentie  Monitor  Metric  Object 
AOM  2528  Mean  and  Min  Max  Monitor  Metric  Object 
AOM  253  Summarization  Objects  (pDISP  12060-x) 

AOM  2531  General  Summarization  CapabWty 

AOM  25311  General  Summarization  Objects 
AOM  2532  Simple  Scanner  Object 
AOM  2533  Dynamic  Scanner  Object 
AOM  2534  Heterogeneous  Scanner  Object 
AOM  2535  Buffered  Scanner  Object 
AOM  2536  Mean  Scanner  Object 
AOM2S37  Mean  Variance  Scanner  Object 
AOM  2538  Percentile  Scanner  Object 

_ AQM2S38  MtiMcSonag-Oatfl _ 

Sources:  WDTR  10000-2.4 .  August  1903;  [SGFS  N  1076],  December  1903. 

OSI  Systems  Management  has  been  accepted  as  a  basis  for  the  TMN,  which  is  specifying 
the  use  of  X.700-series  Recommendations.  ITU-TS  SG  VII  is  thus  continuing  the  maintenance  of 
X.700- series  Recommendations,  developing  additional  Recommendations,  where  needed,  to 
accommodate  advances  in  technology  and  additional  requirements.  [Ref.  SC21  N  6956  1992] 

12.1.5  Military  Concerns  in  Network  Management 

Some  concerns  in  the  OSI  management  area  involve  the  direction  and  support  of  work 
being  done  by  ISO  for  Quality  of  Service  (QoS)  and  multi  peer/multiaddressing.  Both  of  these 
areas  were  reassessed  in  1989  due  to  lack  of  support  from  the  nations.  Specifically,  a  formal 
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question68  has  beat  raised  and  put  to  a  ballot  on  the  need  for  a  framework  for  quality  of  service 
within  the  ISO  standards.  Since  these  areas  have  been  found  to  be  priority  items  for  achieving 
military  requirements,  it  is  important  for  the  Nations  individually  and  collectively  to  express  their 
support  for  additional  work  in  these  standards  areas. 

The  Ad  Hoc  Working  Group  on  OSI  Management  (AHWG-OM)  of  TSGCE  SG9  has  been 
formed  to  address  OSI  management  issues  for  NATO.69  The  major  standing  document  of  the 
AHWG-OM  is  NATO  Requirements  far  Open  Systems  Management  [Ref.  AHWG  1990];  some 
key  elements  are  the  following: 

•  Part  1:  Rationale  and  Objective  (of  which  Section  7  is  Military  Features  and  Their 
Impact  on  OSI  Management  and  Annex  A.2  is  die  Work  Plan),  June  1990 

•  Annex  H:  Notes  Concerning  the  Quality  of  Service  Issue,  Third  Draft,  February  1990 

•  Appendix  4,  Requirements  far  a  Network  Management  Broadcast  Facility,  May  1990. 

12.1.6  Quality  of  Service  (QoS) 

In  the  framework  of  OSI,  QoS  provides  the  capability  to  measure  die  service  level  provided 
by  the  communications  service  provider  and  the  means  to  request  a  target  service  from  the 
communications  service  provider.  QoS  parameters  now  used  in  ISO  standards70  include  transit 
delay  and  priority. 

SC21/WG1  posed  Question  62  (Q62)  in  1989  to  query  whether  a  QoS  Architecture  was 
necessary  since  such  an  architecture  would  require  modification  to  the  OSI  Reference  ModeL  The 
first  step  to  developing  such  an  architecture  would  be  defining  the  components  of  a  QoS 
Framework.  A  concern  of  several  national  bodies  in  WGl  is  that  a  new  QoS  Architecture  would 
destabilize  the  existing  standards.  At  the  May  1990  SC21  Plenary  in  Seoul,  WGl  did  not  progress 
the  QoS  Framework  as  a  new  work  item.  In  May  1991,  WGl  reported  to  SC21  the  final  answer 
to  Q62,  saying  that  there  was  indeed  a  need  for  a  QoS  framework.  [Ref.  SC21  N  6158  1991]  In 
June  1991,  it  was  again  proposed  as  a  new  work  item  [Ref.  SC21  N  6159  1991],  which  was 
accepted  into  the  work  program  in  February  1992. 

The  Framework  on  Quality  of  Service,  August  1993,  in  development  by  SC21/WG1  since 
May  1992,  has  reached  a  second  working  draft  [SC21  N  7993]  and  is  expected  to  become  a  PDTR 
at  tiie  mid  of  1994  (initiation  of  ITU-TS  approval  expected  in  1997).  It  provides  a  framework  for  a 
coherent  treatment  of  QoS  across  all  OSI  standards  and  extends  the  current  (uncoordinated)  QoS 
requirements.  Based  largely  on  X.25,  it  will  support  new  protocols  for  multi-media 
communications  in  SC6  and  time  critical  communications  in  TCI 84,  as  well  as  new  technologies 
for  public  networks.  The  framework  contains  the  following  [Ref.  DRA 1994]: 

•  Common  set  of  concepts  and  definitions,  including  a  model  of  the  layer  and  system 
entities  that  participate  in  QoS 

•  Collection  of  definitions  of  QoS  mechanisms,  such  as  negotiation  procedures. 


68  ISCVIEC  JTC1/SC21/WG1  Question  62:  Ts  Quality  of  Service  an  architectural  issue  which  needs  overall 
guidance  and  consistent  approach  across  all  layers?"  Balloting  dosed  in  May  1989. 

69  The  work  TSGCE  SG9  working  groups  is  discussed  k>  Section  17.3.  The  AHWG-OM  is  addressed  in  Section 
17.3.5. 

70  ISCVIEC  references  to  QoS  are  in  Layer  3  (ISO  8438),  Layer  4  (ISO  8072,  8073),  Layer  5  (ISO  8326), 
Layer  6  (ISO  8822),  and  Layer  7  (ISO  8649. 8650, 8571-3). 
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Issues  not  yet  resolved  in  the  August  1993  QoS  Framework  are  treatment  of  guaranteed  QoS, 
sharing  of  systems  management  information,  use  of  QoS  by  applications,  dynamic  use  of  QoS, 
and  predictability  and  confidence  levels  including  issues  of  precision  and  granularity  [Ref. 
SC21  N  7992].  A  separate  document  [SC6  N  7989]  of  SC6  identifies  and  categorizes  QoS 
parameters  [Ref.  SC21  N  8262  1993]. 

In  the  1993-1996  Study  Period,  ITU-TS  SG7  will  continue  to  study  the  question  of 
Network  Performance  and  Quality  of  Service  in  Data  Communication  Networks  (Study 
Question  4).  [Ref.  SC21  N  6956  1992]  In  October  1993,  SG7  informed  SC21  that  SG7  had 
agreed  to  collaborate  with  SC21  to  develop  the  architecture  for  OSI  QoS,  covering  all  seven  of  the 
OSI  layers,  with  the  stated  intention  to  make  the  result  an  ITU-TS  recommendation  [Ref. 
SC21N8263  1993]. 

The  AHWG-OM  has  identified  [Ref.  SG9AVG1  1990a;  AHWG-OM  1989]  the  following 
deficiencies  and  requirements  relative  to  QoS: 

•  Only  static  QoS  parameters  have  been  defined — the  relationship  of  various  QoS 
parameters  to  each  other  and  actions  to  take  upon  dynamic  change  in  QoS  are  not  yet 
supported. 

•  A  tight  coupling  between  QoS  and  communications  services  is  needed  to  support 
applications  in  areas  such  as  military  and  real-time  process  control  and  high  assurance 
of  message  delivery.  Specifically,  this  means  that  applications  need: 

Capability  to  clearly  express  the  QoS  requirement  to  the  underlying 
communications  service 
Notification  of  changes  in  QoS 
Close  monitoring  of  the  QoS 

Assurance  that  QoS  is  maintained  in  a  deterministic  manner. 

•  While  QoS’s  need  of  the  layer  services  have  led  to  protocol  definitions  that  include 
parameters  for  specifying  QoS,  no  syntax  or  semantic  meaning  of  those  parameters 
has  been  defined. 

Further,  the  AHWG-OM  has  recommended  that: 

•  An  overall  framework  for  OSI  QoS  be  developed  and,  specifically,  ISQ/IEC 
SC21/WG1  raise  the  priority  of  QoS  discussions  in  this  area. 

•  QoS  be  expanded  to  provide  five  functions:  establishment,  monitoring,  maintenance, 
notification  of  change,  and  negotiation. 

•  The  definition  of  QoS  be  modified  to  include  the  following  four  classes  of  QoS 
parameters: 

Quality  of  addressing — the  correct  assignment  of  addresses  to  the  originator  and 
the  recipient 

Quality  of  message — the  reliability  of  message  delivery  against  data  loss,  data 
corruption  or  insertion,  misdelivery,  duplicate  delivery,  or  out-of-sequence 
delivery. 

Quality  of  timeliness — the  delay  of  transferring  information  across  a 
communications  service,  including  specification  of  requirements  on  time  limits  for 
delivery  of  a  message.  The  latter  may  be  in  terms  of  the  time  after  which  the 
message  is  no  longer  valid,  allowable  delay  in  the  transfer,  and  the  action  to  take 
on  failure  to  meet  the  criteria. 

Quality  of  confidentiality — the  ability  of  the  system  to  protect  its  resources  from 
unauthorized  use  and  to  prevent  unauthorized  interception  of  information  relative 
to  the  transfer  of  a  message.  Clearly  this  quality  overlaps  security  requirements. 
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The  AHWG-OM  in  its  meeting  in  June  1990  recommended  three  steps  for  progressing 
work  on  QoS:  (1)  establish  an  ad  hoc  working  group  on  QoS  in  TSGCE  SG9  to  define  QoS 
requirements  and  a  QoS  Framework;  (2)  apply  the  QoS  Framework  in  other  SG9  working  groups; 
and  (3)  provide  additional  information  to  ISO  and  other  standards  bodies  on  the  need  for  QoS. 
AHWG-OM  recommended  that  the  proposed  framework  consider  the  application  QoS  parameters, 
the  application  actions  (procedures  used  by  applications  in  processing  QoS  information),  and  QoS 
facilities  for  establishment,  monitoring,  maintenance,  notification,  and  negotiation  of  QoS.  [Ref. 
AHWG  1990a] 

A  key  background  paper  for  QoS  is  Management  Requirements  Arising  from  a  NATO 
Study  of  Quality  of  Service.  [Ref.  Kennedy  1989]  This  paper  identifies  QoS  requirements  in  such 
areas  as  specification,  establishment,  application  actions,  monitoring,  maintenance,  notification, 
negotiation,  information  flow,  and  applicability.  It  also  addresses  the  QoS  framework, 
information  model,  and  interaction  model.  Four  QoS  parameters  are  identified:  addressing, 
message,  timeliness,  and  confidentiality.  The  June  1990  recommendations  of  the  AHWG-OM  to 
SG9  were  based,  in  part,  on  material  described  in  this  paper. 

12.1.7  Special  Interest  Groups  for  OSI  Management 

A  number  of  special  interest  groups  have  been  formed  to  promote  standardization  of  OSI 
management.  These  include  [Ref.  AHWG  1990b]: 

•  Network  Management  Experts  Group — formed  within  EWOS  with  plans  to  meet  four 
times  per  year. 

•  Network  Management  Forum  (NMForum) — developing  a  roadmap 
(EWOS/TZ/91/214),  an  industry-accepted,  standards-based  concept  that  promotes 
product  interoperability.  The  Roadmap  plan  is  a  path  consisting  of  a  series  of  points  in 
time  (OMNIPoints).  At  each  point  it  is  agreed  that  it  is  sensible  to  build  interoperable 
management  products  to  agreed  interfaces  with  agreed  functionality.  [Ref. 
OSN  1992e]  The  first  OMNIPoint  was  published  in  October  1992  and  brings 
together  SNMP  (see  Section  12.1.9)  and  CMIP  (X.700)  standards.  It  is  already 
referenced  in  the  US  Government  Network  Management  Profile  (GNMP).  [Ref. 
OSN  1992f] 

•  NIST  Network  Management  Special  Interest  Group  (NMSIG) — developing 
specifications  for  the  Stable  Implementor's  Workshop  Agreements  with  a  target  date  of 
December  1990.  The  1990  version  will  define,  in  coordination  with  EWOS  and  the 
NMForum,  managed  objects  for  LANs  including  FDDI,  X.25,  and  ISDN.  Additional 
managed  objects  would  be  defined  in  1991  for  Layer  3-7  protocols  and  routers  and  in 
1992  for  applications,  operating  systems,  and  database  management  systems. 

12.1.8  ECMA  Model  for  Management 

In  January  1987  the  European  Computer  Manufacturers  Association  (ECMA)  established 
[Ref.  ECMA  1987]  an  abstract  model  for  the  management  aspects  of  OSI.  The  framework 
provided  by  ECMA  is  designed  to  form  the  basis  for  the  definition  and  specification  of  services 
and  protocols  that  enable  the  planning,  organizing,  supervising,  and  controlling  of  the 
communication  service  that  forms  a  part  of  a  distributed  information  processing  system.  In  this 
context,  OSI  management  is  defined  as  the  collection  and  interchange  of  information  necessary  for 
the  management  of  those  aspects  of  open  systems  that  are  relevant  to  Open  Systems 
Interconnection.  The  abstract  model  addresses  standardization  in  two  areas: 

•  Semantics  of  the  management  information  transferred  or  extracted  from  the 
management  information  base  (where  the  structure  of  the  information  within  die 
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management  information  base  is  viewed  as  a  local  matter  and  not  subject  to 
management  standardization) 

•  Services  and  associated  protocols  for  the  transfer  of  management  information  between 
open  systems;  this  requires  that  both  the  syntax  and  semantics  of  the  information 
transferred  be  specified. 

ISO  standards  for  OS1  network  management  are  being  developed  by  SC21/WG4;  they  are 
discussed  in  Section  12.1.3. 

12.1.9  Simple  Network  Management  Protocol  (SNMP) 

While  OSI  Systems  Management,  CMIP  is  designed  for  use  in  an  OSI  environment, 
SNMP  is  designed  to  operate  over  TCP/IP  (see  Section  9.7.4).  A  new  version  of  SNMP 
(SNMPv2)  has  been  issued  as  a  draft  standard.  It  addresses  many  of  the  deficiencies  present  in  die 
original  SNMP  and  is  intended  for  use  in  both  TCP/IP  and  OSI  environments.  While  OSI 
Systems  Management  provides  a  more  powerful  and  flexible  scheme  for  representing  management 
information  and  offers  a  richer  set  of  structuring  tools,  SNMPv2  may  enjoy  an  advantage  in 
Security.  SNMPv2  includes  a  well-defined,  easily- understood  security  facility  consisting  of 
access  control,  authentication,  and  privacy.  [Ref.  Stallings  1993] 

12.1.10  Desktop  Management  Interface  (DMI) 

The  Desktop  Management  Interface  (DMI)  standard  (see  Section  15.1.3.10)  aims  to 
standardize  how  desktop  systems  make  status  and  configuration  information  available  to  network 
management  applications.  Vendors  committed  to  supporting  this  standard  include  Novell,  Digital, 
IBM,  Intel,  Microsoft,  Sun-Connect,  and  SynOptics.  A  key  part  of  DMI  is  the  Management 
Information  File  (MIF),  a  database  of  status  and  configuration  information  generated  by 
components  (e.g.,  peripherals,  personal  computers)  in  the  network.  DMI-compliant  management 
applications  running  on  a  system  such  as  HP’s  OpenView  can  collect  the  information  from  the 
desktop  to  do  inventory  management,  accounting,  and  real-time  diagnostics.  [Ref.  RNLA  1994, 
pp.  29-30] 

12.2  Standards  for  Conformance  Testing 

Conformance  testing  is  crucial  to  the  achievement  of  OSI  to  ensure  comparability  of  test 
procedures  and  results  by  different  test  centers.  Conformance  testing  is  defined  by  the  United 
Kingdom's  National  Centre  for  Information  Technology  as  [Ref.  Pink  1991]  as  "the  testing  of  a 
product  against  a  published  standard  in  order  to  determine  the  degree  of  conformance  with  that 
standard.” 

12.2.1  Conformance  Testing  Methodology,  Framework,  Issues,  and 
Assessment 

12.2.1.1  ISO/IEC  9646  on  Conformance  Testing  Methodology  and 
Framework 

Standardization  of  conformance  test  suites  needs  to  be  based  on  a  standard  testing 
methodology  and  approach  to  test  suite  specification,  which  is  reflected  in  ISO/IEC  9646,  OSI 
Conformance  Testing  Methodology  and  Framework  (CTMF).  Work  has  already  begun  in 
standardizing  test  suites  based  on  ISO/IEC  9646  for  X.25  terminals,  the  connection-oriented 
transport  protocol  (ISO  8073),  MHS,  FT AM,  ACSEs,  session,  and  presentation  protocols.  A 
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detailed  description  of  OSI  conformance  testing  is  provided  in  [Ref.  Rayner  1987].  ISO/IEC  work 
in  conformance  testing  is  done  by  SC21/WG1. 

ISO/IEC  9646  is  being  developed  in  seven  parts,  five  of  which  have  achieved  IS  status. 
The  seven  parts,  together  with  the  current  amendments,  are  as  follows  [Ref.  DRA 1994]: 

•  ISO/IEC  9646-1  (Part  1):  General  Model,  July  1991  (ITU-TS  X.290)— gives  an 
overview  of  the  conformance  testing  process  by  introducing  the  basic  ideas  of  the 
meaning  of  conformance,  implementation  conformance  statements,  test  methods,  test 
suites  and  their  components,  and  general  terminology.  A  revision  incorporating  the 
following  two  amendments  is  in  progress  (IS  text  expected  March  1994): 

AM  1,  Protocol  Profile  and  Multi-Protocol  Testing,  October  1993  [SC21  N  7321] 

-  AM  2,  Multi-Party  Testing,  October  1993  [SC2 1  N  7322] 

•  ISO/IEC  9646-2  (Part  2):  Abstract  Test  Suite  Specification,  July  1991 
(ITU-TS  X.291) — applies  to  test  suite  suppliers,  defines  in  detail  the  different  test 
methods,  and  gives  requirements  and  guidance  for  the  test  suite  development  process 
applicable  to  base  protocol  standards.  A  revision  incorporating  the  following  two 
amendments  is  in  progress  (IS  text  expected  March  1994): 

AM  1,  Protocol  Profile  and  Multi-Protocol  Testing,  October  1993  [SC21  N  7323] 

-  AM  2,  Multi-Party  Testing,  October  1993  [SC21  N  7324] 

•  ISCVIEC  9646-3  (Part  3):  The  Tree  and  Tabular  Combined  Notation  (TTCN),  October 
1991  (ITU-TS  X.292)— defines  he  test  specification  language  recommended  for 
standardized  test  suites  in  all  the  layers  of  the  OSI  Reference  Model  except  the  Physical 
Layer.  It  enables  abstract  test  suites  to  be  written  in  sufficient  detail  to  determine 
unambiguously  the  verdicts  to  be  assigned  when  test  cases  are  run  without  being 
specific  to  a  given  executable  language  or  test  system.  It  has  both  a  human  readable 
(TTCN.GR)  and  a  machine-processable  (TTCN.MP)  form. 

-  AM  I,  TTCN  Extensions,  October  1993  [SC21  N  7528] 

-  DAM  2,  TTCN  Further  Extensions,  December  1993  [SC21  N  8374] 

•  ISO/IEC  9646-4  (Part  4):  Test  Realization,  May  1991  (ITU-TS  X.293)— applies  to 
test  realizers  and  gives  requirements  and  guidance  for  the  production  of  a  means  of 
testing  an  abstract  test  suite.  The  means  of  testing  encompasses  the  test  system,  the 
executable  test  suite,  the  means  of  performing  test  selection  and  parameterization,  and 
the  means  of  realizing  control  and  observation  of  the  system  under  test.  The  main 
requirements  concern  the  means  of  production  of  a  conformance  log  to  present  what 
occurred  during  testing  in  a  way  that  is  human-readable  and  related  to  the  abstract  test 
cases  concerned.  A  revision  incorporating  the  following  two  amendments  is  in 
progress  (IS  text  expected  March  1994): 

AM  1,  Protocol  Profile  and  Multi-Protocol  Testing,  October  1993  [SC21  N  7325] 

-  AM  2,  Multi-Party  Testing,  October  1993  [SC21  N  7326] 

•  ISO/IEC  9646-5  (Part  5):  Requirements  on  Test  Laboratories  and  Clients  for  the 
Conformance  Assessment  Process,  May  1991  (ITU-TS  X.294) — specifies 
requirements  and  gives  additional  guidance  for  both  the  test  laboratory  and  the  client 
for  the  whole  of  the  conformance  assessment  process  (i.e.,  before,  during,  and  after 
the  execution  of  the  selected  test  cases).  General  proformas  are  provided  for  test 
reports.  Accreditation  bodies  look  for  compliance  of  test  laboratories  to  this  part  when 
they  assess  OSI  test  laboratories  for  accreditation.  A  revision  incorporating  the 
following  two  amendments  is  in  progress  (IS  text  expected  March  1994): 

AM  1,  Protocol  Profile  and  Multi-Protocol  Testing,  October  1993  [SC21  N  7327] 

AM  2,  Multi-Party  Testing,  October  1993  [SC21  N  7328] 
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•  ISO/IEC  9646-6  (Part  6):  Protocol  Profile  Testing  Specification,  October  1993 
[SC21  N  7329]  (balloting  ended  April  1993  and  editing  meeting  held 
September  1993)— equivalent  to  Part  2  for  profiles  rather  than  for  individual 
protocols;  give  guidance  on  the  meaning  of  conformance  to  a  profile  and  gives 
requirements  and  guidance  for  the  profile  test  specification  process. 

•  DIS  9646-7  (Part  7):  Requirements  and  Guidelines  on  Implementation  Conformance 
Statement  (ICS)  and  ICS  Proformas,  October  1993  [SC21  N  8180]  (balloting  ends 
April  1994) — specifies  requirements  and  guidance  on  statements  made  to  claim 
conformance  for  a  product  to  one  or  more  OSI  specifications.  It  draws  together  and 
generalizes  information  on  this  subject  from  a  variety  of  older  sources,  including 
Parts  2  and  6  of  ISO/IEC  9646  and  ISO/IEC  TR  10000-1.  It  applies  to  statements 
made  for  conformance  to  protocols,  protocol  profiles,  and  information  objects.  When 
such  an  implementation  conformance  statement  is  used  in  conformance  testing,  it 
determines  which  options  are  to  be  tested. 

The  amendments  noted  above  have  the  following  scope: 

•  Protocol  Profile  Conformance  Testing  Methodology  (PPTM)  extends  the  OSI 
conformance  testing  methodology  and  framework  (ISO/IEC  9646)  to  make  it 
applicable  to  OSI  protocol  profiles  as  well  as  base  protocols.  This  standard 
supersedes  TR  10000- 1  as  far  as  conformance  aspects  are  concerned. 

•  Multi-party  Test  Methods  (MPTM)  addenda  define  the  main  requirements  concerning 
MPTM  and  a  multi-party  test  architectural  model.  The  model  will  be  used  to  map 
abstract  test  methods  on  which  to  base  the  development  of  abstract  test  suites  and 
means  of  testing  for  the  various  multi-party  protocols  and  multi-party  testing 
configurations  using  more  than  one  protocol  or  more  than  one  channel 

•  TTCN  Extensions  introduces  the  notion  of  parallelism  in  order  to  ease  the  writing  of 
test  cases,  provide  a  language  means  to  describe  explicitly  the  cooperation  of 
(distributed)  components  of  a  test  architecture,  and  to  make  TTCN  a  test  notation  that 
covers  the  aspects  of  a  multi-party  test  methodology. 

Additional  topics  to  be  addressed  for  conformance  testing  are  ISDN  and  multimedia  concerns, 
application  of  formal  methods;  and  protocols  for  test  support 

12.2.1.2  Other  Conformance  Testing  Standards  Work 

Formal  Methods.  Formal  Methods  in  Conformance  Testing  (FMCT)  is  a 
complementary  standard  to  ISO/IEC  9646  that  specifies  a  general  methodology  for  performing 
conformance  of  a  protocol  implementation,  given  a  formal  specification  of  the  protocol  standard.  It 
includes  the  following  [Rtf.  DRA  1994]: 

•  Establishment  of  a  theory  and  framework  leading  to  a  formal  testing  methodology  that 
may  be  used  to  establish  and  assess  conformance  of  an  implementation  under  test 
(IUT)  to  behaviors  described  in  the  formal  description  of  the  protocol 

•  Definition  of  a  test  methodology  that  includes  descriptions  of  test  entities  (e.g., 
upper/lower  testers,  protocol  entities  augmented  with  testing  functions)  applicable  to 
single-layer,  multi-layer,  and  multi-party  conformance  testing 

•  Definition  of  a  methodology  for  automatic  generation  and  validation  of  test  suites  from 
formally  specified  protocol  entities. 

It  is  currently  in  WD  status  [SC21  N  7995,  September  1993]  with  a  collaborative  meeting  with 
ITU-TS  SG10(Q/10)  in  February-March  1994;  CD  text  is  expected  in  June  1994  and  initiation  of 
the  ITU-TS  ballot  approval  in  1997. 
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SC21/WG9.  A  joint  working  group  (WG9)  was  established  by  SC21  in  June  1993  to 
publish  a  technical  report  on  the  topic:  interpretation  of  accreditation  requirements  as  specified  in 
ISO  Guide  25  for  information  technology  and  telecommunications  testing  laboratories  for  software 
and  communications  testing  services.  Publication  is  expected  December  1994. 

Testing  with  Non-OSI  Protocols.  Two  new  work  items  related  to  non-OSI 
protocols  were  approved  by  the  SC21  Plenary  in  June  1993  to  be  forwarded  to  SC21: 

•  Conformance  Testing  of  OSI  Protocols  over  OSI  Services  Provided  by  Non-OSI 
Protocols  [SC21  N  801 1,  July  1993] 

*  Extensions  to  ISO/IEC  9646  on  Testing  of  OSI  Protocols  over  OSI  Services  Provided 
by  Non-OSI  Protocols  [SC21  N  8016.  June  1993] 

These  would  address  some  of  the  testing  issues  associated  with  coexisting  protocol  stacks  from  the 
Internet  (TCP/IP)  and  OSI.  The  first  proposal  [SC21  N  801 1,  August  1993]  was  not  accepted  by 
JTC1. 

Conformity  Assessment  At  its  March  1993  Plenary  in  Berlin.  JTC1  established  a 
standing  Special  Working  Group  on  Conformity  Assessment  (SWG-CA).  The  first  meeting  was 
held  in  September  1993  and  another  in  January  1994.  [Ref.  SC21  N  7713  1993]  SC21  approved 
a  new  work  item  proposal  to  be  forwarded  to  JTC1  on  Open  Systems  Assessment  Methodology 
[SC21  N  8010.  June  1993];  this  proposal  would  have  generalized  ISO/IEC  9646  to  Open 
Distributed  Processing  (ODP),  open  system  environment  (OSE)  profiles,  and  network 
management  standards,  but  it  was  not  accepted  by  JTC1. 

Work  on  ODP  conformance  testing  was  die  basis  of  the  new  work  item  on  Open  Systems 
Assessment  Clearly,  much  of  the  OSI  conformance  testing  methodology  and  framework  can  be 
applied  to  ODP,  and,  some  extent,  this  has  already  been  done  in  specifications  of  the  Protocol 
Profile  Testing  Methodology,  Multi-Party  Testing  Methodology,  and  Implementation  Conformance 
Statements.  The  proposed  new  work  item  would  have  addressed  the  necessary  terminology  and 
general  concepts  applicable  to  OSE  profiles,  APIs,  and  network  management  as  well  as  to  ODP. 
[Ref.  SC21  N  8010  1993] 

Convergence  of  conformance  testing  methodologies  for  OSI  and  ODP  will  need  to  be 
addressed,  whether  or  not  the  conformity  assessment  methodology  is  finally  accepted  in  some 
revised  (reduced  scope)  form.  In  December  1993,  the  JTC1/SGFS  requested  SC21/WG1  and 
SC22/WG15  to  investigate  convergence  of  their  activity  on  conformance  testing  and  development 
of  a  plan  and  time  table  for  convergence  if  practical,  or  a  rationale  for  concluding  convergence  is 
not  practical.  In  the  latter  case,  the  SGFS  asked  for  recommendations  on  how  to  proceed  with 
overlapping  OSE  and  ODP  requirements  in  this  area.  (Conformity  assessment  related  to  OSE  is 
addressed  in  Section  15.3). 

Tearing  Secure  Open  Systems.  The  UK  National  Physical  Laboratory  has  prepared  a 
report.  The  Requirement  for  a  Methodology  to  Test  Secure  Open  Systems,  September  1993.  This 
report  outlines  the  required  framework  for  a  methodology  that  integrates  conformance  testing  and 
security  evaluation,  as  a  means  to  test  secure  open  systems. 

12.2.1.3  Conformance  Testing  Issues 

SC21/WG1  has  noted  concerns  [Ref.  SC21  N  4187  1989]  about  the  available  resources 
and  direction  of  work  on  upper  layer  conformance  testing.  Work  has  slipped  2  years  on  abstract 
test  mites  for  FT AM  and  3  years  for  embedded  test  suites  for  ACSE,  Presentation  Layer,  and 
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Session  Layer.  There  is  an  imbalance  between  work  on  the  basic  methodology  and  that  applied  to 
the  actual  conformance  tests,  specifically  on  abstract  test  suites. 

Moreover,  some  OSI  certification  agencies  will  not  certify  FT AM  implementations  as 
conformant  when  the  implementation,  in  the  role  of  an  initiator,  does  not  employ  all  possible 
protocol  variations,  even  though  the  protocols  that  are  used  completely  support  the  services  of  that 
implementation.  Although  the  problem  presently  concerns  FT AM,  the  same  problems  will  occur  in 
products  implementing  other  standards  where  there  is  an  asymmetric  relationship  between 
correspondents  and  where  the  initiator  controls  the  protocol  that  will  be  exchanged.  The  United 
States  therefore  recommends  that  SC21  begin  the  following  efforts  [Ref.  X3  1992e]: 

•  ISO/IEC  9646  be  amended  to  give  warning  and  guidance  for  standards  needing  to 
incorporate  a  clause  describing  the  conformance  requirements  for  the  sender  aspects  of 
the  protocol. 

•  Those  standards  with  specific  sender  requirements  must  clarify  their  claims  of 
conformance  to  indicate  permitted  conformance  subsets. 

•  Upcoming  standardized  APIs  will  mandate  the  need  for  service  testing.  SC21  should 
begin  studying  the  relationships  between  protocol  machines  and  the  service/user 
interface. 

•  SC21  should  reaffirm  that  conformance  statements  about  the  definition  of  conformance 
subsets  are  the  responsibility  of  base  standards,  not  of  Registration  Authority  Test 
Labs,  workshops,  etc. 

•  It  should  be  possible  to  allow  PICS  to  describe  varied  protocol  uses  based  on  the 
context  in  which  the  protocol  machine  is  used. 

Other  conformance-related  problems  have  been  noted.  The  concepts  of  general  and 
dependent  conformance  are  being  misused  and  misunderstood  (see  also  Section  12.1.2.5).  An 
ISQ/IEC-ITU-TS  Joint  OSI  Conformance  Group  Interim  Meeting  in  Durham,  North  Carolina,  in 
November  1991  issued  a  health  warning  on  this  topic  for  general  consumption  and  produced  a 
liaison  statement  to  WG4  in  the  hope  that  some  National  Bodies  would  take  note  of  the  concerns  in 
relation  to  any  relevant  ballots.  Furthermore,  there  are  serious  problems  with  the  double  column 
status  notation  meaning  and  use.  Again,  a  health  warning  paper  was  produced.  [Ref. 
SC21  N  6819  1992] 

Since  there  is  as  yet  no  suitable  home  for  information  relating  OSI  conformance  to  ODP 
conformance,  a  new  question  was  to  be  raised  at  the  Plenary  in  June  1992  to  tackle  this  problem. 
Finally,  there  were  inadequate  contributions  to  progress  any  of  the  further  TTCN  extension  topics 
satisfactorily.  Therefore,  DAM  2  to  9646-3  includes  calls  for  contributions  on  all  other  topics. 
[Ref.  SC21  N  6819  1992] 

In  May  1992,  the  UK  proposed  a  new  question  (Ql/69)  on  conformance  assessment  for 
OSI  security  in  order  to  assess  the  proper  scope  for  a  new  work  item  proposal  and  the  appropriate 
time  scale  for  it.  A  basic  assumption  of  the  ISO/IEC  9646  conformance  testing  methodology  is 
that  bugs  in  an  implementation  will  be  unintentional  and  therefore  not  deliberately  hidden.  In  OSI 
security  this  assumption  is  false,  and  there  is  a  need  to  test  implementations  for  breaches  of 
security  such  as  Trojan  horses,  trap  doors,  or  viruses.  [Ref.  SC21  N  7098  1992] 

EWOS  has  agreed  [ITSTC  1989]  to  convene  an  activity  to  study  and  investigate  OSI 
Conformance  Testing  Methodology.  This  work  would  examine  central  aspects  of  OSI  testing 
methodology  that  are  necessary  to  support  standardization  of  test  specifications.  CEN  has  been 
assigned  leadership  of  the  work. 


Chapter  12 


286 

UNCLASSIFIED 


System  Management 


UNCLASSIFIED 


12.2.1.4  TTCN 

TTCN  (ISO/IEC  9646-3)  is  a  unique,  informal  notation  that  was  developed  by  ISO  and 
ITU-TS  for  specifying  generic  and  abstract  test  cases.  Other  formal  description  techniques  in  use 
for  this  purpose  are  the  Language  of  Temporal  Ordering  of  Specification  (LOTOS)  and  Estelle — 
both  accepted  in  the  NTIS  Transition  Strategy — and  the  System  Development  Language  (SDL), 
developed  by  ITU-TS  (Recommendation  Z.100).  Both  Estelle  and  SDL  are  Pascal-based 
notations.  These  formal  description  techniques  (FDTs)  are  described  in  detail  in  Section  12.2.3. 

TTCN  provides  a  notation  in  which  generic  and  abstract  test  cases  can  be  expressed  in  test 
suite  standards;  which  is  independent  of  test  methods,  layers,  and  protocols;  and  which  reflects  die 
abstract  testing  methodology  of  ISO/IEC  9646.  TTCN  provides  a  naming  structure  to  reflect  the 
position  of  test  cases  in  the  abstract  test  suite  hierarchy  (complete  test  suite,  test  groups,  test  cases, 
test  steps,  and  test  events).  TTCN  also  provides  the  means  of  structuring  test  cases  as  a  hierarchy 
of  test  steps  culminating  in  test  events. 

EWOS  has  circulated  for  ratification  a  revision  of  The  TTCN  Style  Guide,  EWOS 
Technical  Guide  025  (Revision  1),  October  1993.  ETSI  intends  to  use  dm  document  on  a  field  trial 
basis  before  formally  approving  it. 

12.2.1.5  Organizations  Contributing  to  Conformance  Testing 

Many  organizations  other  than  ISO/IEC  have  been  formed  to  address  OSI  conformance 
testing.  These  include  Corporation  for  Open  System  (COS),  OSINET,  Standards  Action  and 
Promotion  Group  (SPAG,  European  Committee  for  Standardization  (CEN)/European  Committee 
for  Electrotechnical  Standardization  (CENELEC),  NIST,  Industrial  Technology  Institute  (l  l'l). 
World  Federation  of  Manufacturing  Automation  Protocol  (MAP)  and  Technical  and  Office  Protocol 
(TOP)  User  Groups,  Conformance  Testing  Services-Wide  Area  Network  (CTS-WAN),  National 
Computing  Centre  (NCC),  and  EurOSInet  TSGCE  SG9  is  addressing  [Ref.  CA  1989]  military 
requirements  in  this  area  and  whether  NATO-specific  activities  need  to  be  supported.  The 
following  are  areas  in  which  existing  civil  organizations  may  be  expected  to  contribute  to 
conformance  testing  to  support  military  requirements  [Ref.  Cardonna  1988]: 

•  Developing  standards  and  conformance  certification  criteria:  ISO,  ITU-TS 

•  Developing  abstract  test  suites  for  OSI  upper  layers:  ISO 

•  Developing  test  profiles  and  provisioning  testing  under  military  requirements:  COS, 
SPAG 

•  Developing  site  accreditation  criteria:  Industrial  Technology  Institute  (TTI) 

•  Implementing  site  accreditation  and  testing  tools,  and  specifying  test  control  and 
maintenance  procedures:  NIST 

•  Developing  standards  and  test  methodologies:  CEN/CENELEC,  ANSL 

COS  [Ref.  COS  1989]  and  SPAG  have  now  completed  formal  agreement  to  combine  their 
conformance  test  products  within  a  single  integrated  tool  set  (ITS).  In  addition,  COS,  POSI,  and 
SPAG  have  completed  (June  1989)  an  Initial  Strategic  Technical  Cooperation  Agreement  that 
commits  the  organizations  to  a  strategic  cooperative  arrangement  designed  to  provide  a  common 
technical  solution  to  conformance  testing,  building  upon  the  ITS.  The  agreement  is  also  known  as 
"CPS"  (both  for  Conformance  Promotion  Strategy  and  for  COS-POSI-SPAG). 
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OS1NET,  a  5 5- member  United  States-based  interoperability  testing  organization,  has  voted 
to  reorganize  under  the  auspices  of  COS.  OSINET  was  formed  in  1984  under  the  auspices  of 
NIST  to  work  in  three  specific  areas: 

•  Research  and  development  of  test  scripts  used  in  OSI  interoperability  testing 

•  Interoperability  resting  and  registration  of  announced  OSI  products 

•  Demonstration  and  promotion  of  OSI  technology  [Ref.  OSN  1991h]. 

There  is  a  need  to  harmonize  resting  and  certification  schemes  to  enable  mutual  recognition 
of  results  of  resting  internationally.  In  1985,  the  Conformance  Test  Service  (CTS)  was  set  up 
under  the  CEN/CENELEC  to  support  the  development  of  test  tools  and  provision  of  test  services. 
In  Phase  I  (1985-1986),  it  addressed  the  following  topics:  OSI  protocols,  software  quality, 
programming  languages,  and  GKS.  In  Phase  II  (1987-1988),  it  continued  to  address  OSI 
protocols  as  well  as  SGML,  ODA,  POSIX,  and  the  programming  language  C.  Memorandum 
M-IT-03  defines  a  framework  for  resting  and  certification  in  Europe  which  aims  to  enable  mutual 
recognition  of  results  of  testing.  The  European  Committee  for  IT  Testing  and  Certification 
(ECITC)  is  implementing  M-IT-03  by  setting  up  mechanisms  for  mutual  recognition  of  rest  reports 
and  certificates  These  include  abstract  test  suites  and  recognition  of  test  tools,  services,  and  tested 
products.  The  Open  Systems  Testing  Consortium  (QSTC)  was  formed  in  1989  on  completion  of 
the  CTS  project  to  ensure  continued  harmonization.  [Ref.  Pink  19911 

12.2.2  PICS  Proformas 

An  approach  used  in  conformance  testing  (and  in  other  applications)  to  specify 
interoperability  parameters  for  an  implementation  profile  (or  a  functional  profile)  is  called  a 
protocol  implementation  conformance  statement  (PICS).  A  PICS  specifies  all  the  parameters  and 
options  required  to  show  how  a  particular  implementation  meets  static  conformance  requirements. 
As  such,  it  is  the  first  tool  in  conformance  resting,  A  PICS  proforma  is  a  PICS  template  developed 
and  standardized  in  conjunction  with  a  protocol  standard.  In  the  future,  a  PICS  proforma  can  be 
expected  to  be  required  as  part  of  the  functional  profile  guidelines  being  developed  by  NIST, 
EWOS,  AOW,  NATO,  and  other  standards  bodies, 

There  are  many  projects  involving  the  development  of  PICS  proformas,  including  an 
Annex  of  ISO/IEC  9646-2,  Guidelines  for  PICS  Proformas,  Guidelines  for  PICS  Proformas  in 
SC6,  Catalogue  of  PICS  Proforma  Notations,  and  TR  10000-1.  The  Arles  meeting  of  SC21  in 
May  1991  initiated  an  NP  for  ISO/IEC  9646-7  to  put  in  one  place  all  of  the  agreed  requirements 
and  guidance  related  to  PICS,  Profile  Implementation  Conformance  Statements  (ICSs),  and 
Information  Object  ICSs. 

Confusion  has  recently  arisen  regarding  the  use  of  the  PICS  in  the  conformance  assessment 
process.  Specifically,  does  the  PICS  describe  the  supplier's  product  or  the  supplier’s  protocol 
implementation?  The  United  Stares  contends  that  it  is  the  latter  and  proposes  that  clarifying  text  be 
added  to  ISO  9646-7.  [Ref.  SC21  WG1  N  1156  1992) 

12.2.3  Formal  Description  Techniques  (FDTs) 

FDTs  arc  used  to  produce  unambiguous  descriptions  of  OSI  services  and  protocols  in  a 
more  precise  and  comprehensive  way  than  natural  language  descriptions.  Further,  FDTs  provide  a 
foundation  for  analysis  and  verification  of  a  description.  The  objectives  of  FDTs  are  to  provide 
[Ref.  DRA  1994): 
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•  Unambiguous,  clear,  and  concise  specifications 

•  Basis  for  determining  completeness  of  specifications 

•  Foundation  for  analyzing  specifications  for  correctness,  efficiency,  etc. 

•  Basis  for  determining  consistency  of  specifications  relative  to  each  other 

•  Basis  for  implementation  support. 

There  are  three  international  standard  FDTs  that  range  from  abstract  to  implementation- 
oriented:  Estelle,  LOTOS,  and  SDL.  Since  emerging  standards  are  being  written  in  one  or  more 
of  these  FDTs,  subsections  are  provided  below  to  give  some  technical  information  together  with 
the  basis,  derivation,  and  character,  for  these  description  techniques.  TR  10167,  Guidelines  for 
the  Application  of  Estelle,  LOTOS,  and  SDL,  July  1991,  provides  guidelines  for  applying  these 
three  FDTs.  A  fourth  FDT — TTCN  (ISO/IEC  9646-3) — was  described  in  Section  12.2.1.4 
above. 

SC21/WG1  developed  a  working  draft  for  Architectural  Semantics  for  FDTs 
[SC21  N  4231,  April  1990].  This  work  was  planned  to  assist  development  of  formal 
descriptions  of  standards  for  data  communications,  networking,  and  distributed  computing.  The 
draft  defines  and  catalogues  a  set  of  selected  elementary  concepts,  which _  t  as  a  bridge  between 
the  architectural  concepts  and  structures  and  the  semantic  models  of  the  FDTs  (Estelle,  LOTOS, 
and  SDL).  SC 21  approved  the  May  1990  recommendations  developed  by  a  reassessment  of  the 
woik  associated  with  the  Architectural  Semantics  for  FDTs.  The  current  work  in  SC21/WG1  will 
be  terminated  and  a  subproject  initiated  in  SC21/WG7  in  the  area  of  ODP  architectural  semantics. 
[Ref.  SC21N  4655  1990] 

An  article  by  L.  Simon  and  L.S.  Marshall  entitled,  "Using  VDM  to  Specify  051  Managed 
Objects,"  in  Proceedings  of  Third  International  Conference  on  Formal  Description  Techniques 
(FORTE  VI),  November  1991,  Sydney,  is  an  example  of  the  use  of  FDTs  in  the  definition  of  the 
behavior  of  managed  objects.  [Ref.  SC21  N  7140  1992] 

12.2.3.1  Estelle 

Estelle  (ISO  9074,  Estelle,  A  Formal  Description  Technique  Based  on  an  Extended  State 
Transition  Model,  July  1989)  is  a  formally-defined  specification  language  for  describing 
distributed  or  concurrent  processing  systems,  in  particular  those  that  implement  OSI  services  and 
protocols.  The  language  is  based  on  widely  used  and  accepted  concepts  of  communicating  non- 
deterministic  state  machines  (automata).  An  Estelle  specification  defines  a  system  of  hierarchically- 
structured  state  machines.  The  machines  communicate  by  exchanging  messages  through 
bidirectional  channels  connecting  their  communications  ports.  These  messages  are  queued  at  either 
end  of  the  channel.  The  actions  of  machines  are  specified  in  (extended)  Pascal;  hence,  familiarity 
with  Pascal  makes  Estelle  specifications  easily  readable.  Estelle  uses  Pascal  data  types  in  its  data 
descriptions. 

Estelle  is  based  on  an  extended  state  transition  model,  i.e.,  a  model  of  a  nondeterministic 
communicating  automaton  extended  by  the  addition  of  the  Pascal  language.  Estelle  may  be  viewed 
as  a  set  of  extensions  to  Level  0  of  ISO  7185  ( Programming  Language  -  Pascal)  that  models  a 
specified  system  as  a  hierarchical  structure  of  communicating  automata  that  may  run  in  parallel  and 
may  communicate  by  exchanging  messages  and  by  sharing,  in  a  restricted  way,  some  variables. 
As  in  Pascal,  all  manipulated  objects  are  strongly  typed,  which  enables  static  detection  (e.g., 
during  compilation)  of  specification  inconsistencies. 


Chapter  12 


289 

UNCLASSIFIED 


System  Management 


UNCLASSIFIED 


Estelle  language  mechanisms  allow  modelling  of  synchronous  and  asynchronous 
parallelism  between  state  machines  of  a  specified  system.  They  also  permit  dynamic  development 
of  the  system  configuration.  Estelle  specifications  can  be  prepared  at  different  levels  of 
abstraction,  from  abstract  to  quite  implementation-oriented.  The  latter  may  be  derived  from  the 
former  with  the  aid  of  supporting  tools.  An  Estelle  tutorial  has  been  developed  (ISO  9074  AM  l, 
January  1992).  ISO  9074,  Estelle,  is  undergoing  revision  to  include  Amendment  I.  This  second 
edition  is  scheduled  to  reach  IS  status  in  December  1994. 

12.2.3.2  LOTOS 

LOTOS  (ISO  8807,  LOTOS,  A  Formal  Description  Technique  Based  on  the  Temporal 
Ordering  of  Observational  Behaviour,  February  1989)  is  a  mathematically-defined  FDT,  developed 
from  a  large,  well-established  body  of  theory  based  on  three  mathematical  techniques:  Calculus  of 
Communicating  Systems  (CCS),  Communicating  Sequential  Processes  (CSP),  and  ACT  ONE. 
Having  a  well-defined  mathematical  foundation,  it  provides  a  solid  basis  for  both  analysis  and 
development  of  reliable  tools,  including  simulation,  compilation,  and  test  sequence  derivation.  The 
basic  constructs  of  LOTOS  allow  modelling  of  sequencing,  choice,  concurrency,  and 
nondeterminism  in  an  entirely  unambiguous  way.  In  addition,  LOTOS  permits  modelling  of  both 
synchronous  and  asynchronous  communication.  LOTOS,  like  SDL,  uses  abstract  data  types  in  its 
data  descriptions. 

LOTOS  may  be  applied  to  produce  a  specification  of  the  allowed  behaviors  of  a  system. 
i.c.,  the  set  of  all  behaviors  that  may  be  observed  of  a  conforming  implementation.  Furthermore, 
LOTOS  permits  the  description  of  allowed  behaviors  without  describing  how  this  may  be  achieved 
or  by  describing  particular  mechanisms  that  achieve  the  required  behavior. 

Formal  descriptions  of  the  session  service  and  protocol  using  LOTOS  have  been 
developed: 

•  TR  957 1,  LOTOS  Description  of  the  Session  Service,  September  1989 

•  TR  9572,  LOTOS  Description  of  the  Session  Protocol,  September  1989. 

WG6  has  developed  PDTRs  for  a  LOTOS  Description  of  the  CCR  Service,  PDTR  11589 
(SC21  N  7876,  June  1993]  and  Protocol  PDTR  11590  [SC21  N  7877,  June  1993]  (see  Section 
9.11.3.2). 

In  addition,  WG1  proposed  a  new  sub-question  on  LOTOS  enhancements  to  redress 
limitations  identified  by  experience  to  date  with  the  language.  The  sub-question  received  strong 
support  in  balloting,  and  it  has  been  proposed  that  a  NWI  on  LOTOS  enhancements  be  initiated. 
The  following  is  a  list  of  possible  enhancements  in  priority  order  [Ref.  SC21  N  70%  1992]: 

•  Define  a  more  user-friendly  notation  for  data-type  descriptions 

•  Compose  a  specification  from  pre-existing  modules  to  promote  reusability  and 
structuring 

•  Consider  mechanisms  to  remove  the  inability  to  express  partial  synchronization  and 
data  exchange 

•  Consider  enhancements  to  allow  specifying  time  and  priorities. 

An  NP  on  Enhancements  to  LOTOS  [SC21  N  8022]  has  gone  out  to  SC21  for  letter  ballot 
on  whether  or  not  NBs  can  commit  to  actively  participate  in  its  development  The  current  draft  of 
this  standard  is  Initial  Draft  on  Enhancements  to  LOTOS,  November  1993  [SC21  N  8023]. 
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The  European  Strategic  Programme  of  Research  and  Development  in  Information 
Technology  (ESPRIT)  LOTOSPHERE  Project  conducted  a  study  from  November  1990  to  April 
1992  on  language  enhancements  to  LOTOS,  which  resulted  in  a  deliverable  on  language 
enhancements.  While  the  proposal  has  not  been  elaborated  to  the  point  that  text  can  be  used 
directly  for  the  revision  of  LOTOS  ISO  8807,  it  is  believed  to  form  an  excellent  basis  for  the 
production  of  such  a  revision.  [Ref.  SC21  WG1  N  1 157  1992] 

12.2.3.3  SDL 

SDL  is  based  (ITU-TS  Z.  100-Series  recommendations)  on  the  extended  finite  state 
machine  model  supplemented  by  capabilities  for  abstract  data  types  based  on  the  initial  algebra 
model  (the  same  one  used  in  the  ACT  ONE  part  of  LOTOS).  This  combination  is  supported  by 
well-defined  formal  semantics.  SDL  provides  constructs  to  present  structures,  behaviors, 
interfaces,  and  communications  links.  In  addition,  it  provides  constructs  for  abstraction,  module 
encapsulation,  and  refinement.  All  of  these  constructs  were  designed  to  assist  die  representation  of 
a  variety  of  telecommunications  systems  specifications,  including  aspects  of  protocols  and 
services. 

12.2.3.4  G-LOTOS 

A  standard  for  a  graphical  syntax,  G-LOTOS,  has  recently  been  approved  that  provides  an 
extension  to  LOTOS  (ISO  8807/AM  1)  to  facilitate  production  and  enhance  clarity  and  readability 
of  formal  descriptions,  simplify  teaching  and  learning  the  language,  favor  the  development  of 
advanced  user-friendly  software  tools,  and  promote  the  diffusion  and  application  of  the  language. 

12.2.3.5  Z  Specification  Language 

Z  is  an  abstract  specification  language;  however,  there  is  no  current  standard  for  Z.  Z  is 
based  on  the  mathematics  of  set  theory  and  predicate  calculus.  Systems  are  described  by 
introducing  fixed  sets  and  variables  and  specifying  the  relationship  between  them.  Current 
applications  of  Z  include  safety-  and  security-critical  systems.  [Ref.  Spivey  1989]  ISO/TTU-TS 
Joint  Modelling  Group  has  suggested  Z  be  considered  as  a  candidate  FDT  for  use  in  ODP  [Ref. 
SC21N6088  1991]. 

12.2.4  Conformance  Test  Suites 

Before  conformance  testing  can  be  conducted,  conformance  test  suites  must  be  specified 
for  each  standard  to  be  addressed.  The  standards  for  conformance  test  suites  typically  have  two 
parts:  Test  Suite  Structure  and  Test  Purposes  and  Abstract  Test  Suite.11  These  form  the  basis  for 
developing  a  conformance  test  and  verifying  its  accuracy.  Examples  of  standards  for  conformance 
testing  are  DIS  8825-4  (Presentation  Protocol)  ISO  8882-2  (X.25),  ISQ/IEC  10025-2  (COTP 
over  CONS).  DIS  10168  (Session  Protocol),  ISO/IEC  10169  (ACSE  Protocol).  ISO/IEC  10170 
(FT AM),  ISQ/IEC  10729  (Presentation  Protocol),  and  ISQ/IEC  10739-1  (Virtual  Terminal). 

In  1989,  NIST  conducted  an  analysis  of  the  OSI  testing  situation  and  concluded  that  unless 
it  acted,  no  credible  means  of  substantiating  GOSIP  compliance  would  be  available  in  time  to 
support  the  US  Government  OSI  mandate  beginning  August  1990.  Abstract  Test  Suites,  where 
they  existed,  were  fragmented  and  not  publicly  available.  Although  multiple  suppliers  of  Means  of 
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Testing  (MOTs)  existed,  no  credible  mechanism  existed  to  assess  MOTs  against  GOSIP 
requirements;  no  means  existed  for  finding  one  MOT  acceptable  and  another  not  Moreover,  no 
program  of  evaluating  and  accrediting  commercial  GOSIP  testing  laboratories  was  planned.  From 
April  through  November  1989,  NIST  defined  a  GOSIP  Testing  Program  and  on  November  13 
issued  a  proposed  COSIP  Conformance  and  Interoperation  Testing  and  Registration  FIPS  for 
public  comment.  [Ref.  Favreau  1990]  On  September  1990,  NIST  published  the  initial  set  of 
registers  ( Register  of  Abstract  Test  Suites  and  Register  of  Assessed  Means  of  Testing  (MOTs)). 
The  Register  of  Accredited  Testing  Laboratories  appeared  May  1991  [Ref.  Martin  1991]  and  now 
contains  more  than  30  MOTs  for  GOSIP  Version  1.0  protocols.  The  US  GOSIP  Register 
Database  (GRD)  is  an  on-line  database  facility  developed  by  NIST  that  provides  up-to-date 
reference  information  on  the  seven  GOSIP  registers  that  arc  currently  available.  It  can  be  accessed 
via  the  Internet  or  directly  via  a  modem.  [Ref.  Favreau  1992]  Section  10.2.1.2  addresses  the 
POSIX  Conformance  Test  Suite. 

12.3  Standards  for  Registration  Authorities 

Registration  provides  unambiguous  identification  of  instances  of  certain  types  of 
information  objects  within  the  OSI  environment.  Examples  of  these  instances  are  an  application 
process,  an  application  entity,  and  the  definition  of  a  class  of  information  such  as  a  file  format. 
Registration  is  the  assignment  of  an  unambiguous  name  to  an  instance  of  a  type  of  information 
object  in  a  way  that  makes  the  assignment  available  to  interested  parties.  It  is  carried  out  by  a 
registration  agent  that  may  be  either  a  standard  or  an  organization. 

SC21  and  ITU-TS  SGVn  have  agreed  to  collaborate  in  work  on  registration  authorities. 
The  groups  have  concurred  that  "the  establishment  and  operation  of  registration  is  critical  to 
communications  in  a  distributed  environment  and  that,  without  procedures  for  the  operation  of 
registration,  interoperability  between  applications  is  unlikely”.  [Ref.  SC 21  N  5014  1990]  An  area 
of  disagreement  is  the  presence  of  the  Name  Form  in  ISO  9834-1,  included  to  support  the 
specification  of  procedures  to  ensure  the  assignment  of  unambiguous  names  for  registration 
purposes. 

SC21/WG1  has  developed72  a  standard  (ISO/IEC  9834,  Procedures  for  the  Operation  of 
OSI  Registration  Authorities)  for  the  operation  of  OSI  registration  authorities.  The  status  and 
structure  of  this  standard  is  as  follows: 

•  ISO  9834-1  (Part  1):  General  Procedures,  April  1993  (ITU-TS  X.660). 

PD  AM  1 ,  Object  Identifier  Component  for  Short  Form  Names 
WDAM  2,  Incorporate  Definition  of  Root  Arcs  of  Object  Identifier  Tree  (WDAM 
expected  August  1994,  PD  AM  December  1994,  DAM  December  1995,  and  AM 
December  1996) 

•  ISO  9834-2  (Part  2):  Registration  Procedures  for  Document  Types,  November  1993 
[SC21  N  8149]  (ITU-TS  X.66 1:1992);  document  types  are  defined  in  ISQflEC 
ISP  10607. 

•  ISO  9834-3  (Part  3):  Registration  of  Object  Identifier  Component  Values  for  Joint 
l SO /ITU-TS  Use,  July  1990  (ITU-TS  X, 662: 1992).  An  amendment  is  being 
prepared  to  align  this  part  with  Part  1;  PDAM  expected  December  1994.  A  further 
amendment  dealing  with  RH-name-tree  has  been  recommended  by  ITU-TS  [SC21  N 
7577],  An  internal  SC21  document,  last  updated  in  August  1991  [SC21  N  6370],  is 

7  2  Work  on  Registration  Authorities  beginning  in  November  1989  was  transferred  to  SC21/WG6. 
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maintained  for  register  of  object  identifier  components  allocated  to  areas  of  joint  ISO- 
ITU -TS  work. 

•  ISO  9834-4  (Part  4):  Registration  of  VTE  Profiles,  December  1991  (ITU-TS 
X.663:1992). 

•  ISO  9834-5  (Part  5):  Registration  of  VT  Control  Objects,  December  1991 
(ITU-TS  X.664:1992). 

•  ISO  9834-6  (Part  6):  Registration  of  AP  Titles  and  AE  Titles,  November  1993 
(ITU-TS  X.665:1992). 

Work  on  registration  authorities  (SC21/WG1)  is  ongoing  in  one  additional  area — 
registration  of  system  titles,  but  this  will  probably  be  incorporated  in  the  management  standards. 
Prior  work  on  authentication  mechanisms,  application  context  names,  abstract  syntaxes,  and 
transfer  syntaxes  (WD  9834-7, 8, 9,  B  and  C)  is  now  considered  as  not  required. 

Question  Ql/49.8  concerning  conformance  and  registration  asks  “What  are  the 
conformance  implications  of  the  registration  of  an  item  for  a  system  that  supports  the  use  of  that 
item  in  conjunction  with  relevant  OSI  protocols  to  which  it  is  claimed  to  conform?”  The  answer, 
which  was  approved  in  November  1992  [Ref.  SC21  N  7471  1992],  states  that  those  requirements 
which  are  clearly  requirements  to  be  met  by  implementations  are  conformance  requirements  and 
should  be  testable  in  accordance  with  ISO/IEC  9646.  However,  those  requirements  that  are  not  to 
be  met  wholly  or  partially  by  users  of  OSI  systems  are  not  testable,  not  conformance  requirements, 
and  not  compliance  requirements.  They  are  called  usage  requirements. 

ITU-TS  Q23/VII,  in  a  liaison  statement  to  SC21,  suggested  that  SC21  initiate  a  joint  work 
to  amend  ISO  9834-3  to  pertain  to  the  join  arc  in  the  RH-name-tree,  rather  than  the  SCN.l  tree. 
[Ref.  SC21N  7577  1993] 

12.4  Assessment 

Quality  of  Service  and  security  arc  not  well  addressed  by  OSI  and  other  open  systems 
standards.  Both  of  these  sets  of  services  require  review  and  possible  modification  of  the  basic 
reference  models  for  open  systems.  They  therefore  could  lead  to  disruption  of  some  of  the 
standards  that  have  already  become  stable  under  the  existing  reference  models. 

Both  sets  of  services  may  be  supported  in  a  wide  range  of  ways,  and  several  approaches  of 
these  may  be  requited  in  information  systems  to  meet  operational  requirements.  For  example, 
quality  of  service  affects  all  the  layers  of  the  OSI  Reference  Model,  and  die  associated  protocols, 
managed  objects,  and  parameters  of  the  protocol  data  units  may  all  have  to  be  extended  to  meet 
military  requirements.  Security  can  be  expected  to  impact  at  least  the  Physical,  Network,  and 
Applications  Layers  of  the  OSI  Reference  Model  (the  NATO  position)  and  other  layers  as  well 
(SDNS  also  provides  a  protocol  for  the  Transport  Layer). 

Work  has  already  begun  on  OSI  services  and  protocols  in  the  management  area.  Systems 
management  is  generally  acknowledged  to  affect  all  service  areas,  especially  operating  system 
services  and  network  services.  The  rally  consensus  achieved  to  date  fra  smnHwrriiring  systems 
management  services  is  in  the  OSI  network  management  area.  Version  1  (June  1992)  of  the 
GNMP  identifies  information  required  for  managing  implementations  incorporating  network 
services  only  at  the  Physical  and  Data  Link  Layers,  and  it  does  not  provide  a  complete  set  of 
managed  object  definitions  or  the  necessary  security  features  fra  network  management. 

Support  for  access  control  and  authentication  is  already  being  incorporated  into  a  number  of 
OSI  standards.  Many  other  aspects  of  security,  such  as  key  management,  still  must  be 

Chapter  12  293  System  Management 

UNCLASSIFIED 


UNCLASSIFIED 


standardized  to  ensure  interoperability  and  to  avoid  building  the  same  functions  many  times  in 
similar  systems  (e.g.,  function-specific  information  systems)  and  in  the  applications  of  a  angle 
system,  such  as  a  CCIS. 

Management  issues  can  be  expected  to  differ  for  each  of  the  technologies  being  considered 
for  information  systems.  For  example,  security  aspects  of  local  area  networks  differ  from  those 
associated  with  broadcast  radio  and  packet-switched  point-to-point  links. 

Some  issues  and  findings  in  security  and  OSI  management  are: 

•  Standards  for  OSI  security  are  evolving,  but  the  evolution  is  slow.  OSI  standards  may 
not  be  satisfactory  in  some  areas  (e.g.,  OSI  services)  in  and  of  themselves  for  military 
applications.  They  may  need  to  be  supplemented  by  application-level  services  outside 
the  OSI  model 

•  An  adequate  treatment  of  management  services  mav  require  modification  to  the  OSI 
Basic  Reference  Model  and  thereby  impact  many  stable  OSI  standards. 

•  Some  management  standards  are  now  stable  (e.g.,  ISO  9595.  ISO  9596;  ISO  10040, 
ISO  10164,  ISO  10165),  but Jhere  is  standardization  required  in  many  additional 
areas. 
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13.  DISTRIBUTED  COMPUTING  SERVICES  Quick  Refere  nee  I 

This  chapter  addresses  standards  for  distributed  Topic  I  Page  I 

computing  services.  It  describes  the  new  IEEE  standard  for  306 

Distributed  Interactive  Simulation  (DIS)  Protocol  Data  Units  Ckcnt^crvcr  206 

(PDU).  the  ISO  standard  for  Open  Distributed  Processing  OORBA  aoi 

(ODP),  the  Object  Management  Group's  (OMG)  work,  the  Open  DCE  302 

Software  Foundation's  (OSF's)  work  on  a  Distributed  Decision  Support  aos 

Computing  Environment  (DCE)  and  Distributed  Management  interactive  Sim.  »e 

Environment  (DME),  the  Message-Oriented  Middleware  Knowledge  Engineer.  305 

Consortium's  (MOM)  work,  the  National  Information  Mkkflewere  304 

Infrastructure  Testbed  (NOT)  and  IBM's  Applications  Peer-to-  ^ 

Peer  Network  (APPN)  protocol.  Distributed  Transaction  OOP  ^ 

Processing  (TP)  is  discussed  with  network  service  standards  in  Omq  301 

Chapter  9  (Section  9. 11.9).  Management  of  distributed  data  and  OSF  302 

other  information  resources  is  discussed  in  Chapter  6  on  Data  LSSSHiSBBg& - 225- 

Management  Services. 

Application  Layer  standards  often  define,  at  least  partially,  distributed  services.  Examples 
are  Message  Handling  System  (MHS),  Remote  Procedure  Call  (RPC),  Directory,  and  File 
Transfer,  Access,  and  Manipulation  (FT AM);  specifically.  Directory  contains  a  specification  of  a 
Directory  Information  Tree  (DIT)  and  its  associated  navigation  rules.  The  nodes  of  the  DIT  for 
ITU-TS  ate  envisioned  to  be  distributed  worldwide.  Such  standards  contain  elements  that  relate  to 
features  (and  models)  of  distributed  applications  and  services,  in  addition  to  features  related  to  data 
transfer. 

General  trends  towards  providing  distributed  systems  functionality  are  through  a  set  of 
servers — the  predominant  interaction  model  is  the  client-server.  The  term  middleware  is 
increasingly  being  used  to  describe  the  software  that  implements  client-server  connectivity.  Two 
principal  approaches  are  used:  RPC  and  message-passing  systems.  [Ref.  RNLA  1994,  p.  26] 

Object-orientation  appears  to  be  developing  into  a  critical  generic  technology  for  distributed 
systems.  Open  operating  systems  are  increasingly  seen  as  a  collection  of  interacting  objects,  with 
the  objects  themselves — representing  the  operating  system  shared  services— being  spread  across  a 
distributed  system.  Further,  objects  are  being  used  as  parts  of  models  of  the  “real  world”  that  a 
particular  distributed  computing  system  is  controlling.  Finally,  objects  are  used  to  represent  the 
shared  services  of  a  distributed  system,  hiding,  for  example,  the  details  of  legacy  systems  by 
enclosing  them  in  wrappers.  The  latter  view  is  especially  important  in  the  standardization  of 
services  for  information  systems.  [Ref.  RNLA  1994,  p.  49] 

The  following  are  examples  of  tasks  being  proposed  in  generic  work  mi  distributed 
applications  [Ref.  IST/21: 1721  1989;  SC21  N  4320  1990]: 

•  Model  tiie  information  held  by  distributed  applications  and  address  the  issues  of 
distribution  and  local  transparency  (the  ODP  work  has  chosen  to  recognize  five 
different  viewpoints  from  which  various  features  of  a  distributed  application  can  be 
modelled);  Modelling  far  Communications  Aspects  of  Distributed  Applications  had 
been  accepted  by  JTC1  and  assigned  to  SC21/WG6.  [Ref.  SC21  N  4911  1990] 
However,  WG6  has  recommended  that  the  project  be  deleted  from  the  program  of 
work  since  it  lacks  an  editor  and  target  dates  and  has  been  inactive. 
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•  Formalize  management  interactions  between  application  processes  in  specific  protocols 
in  such  functions  as  establishing  relationships,  distributing  data,  and  replicating  data. 

•  Devise  global  security  mechanisms  for  use  throughout  the  entire  domain  of  the 
distributed  application. 

•  Enable  the  schema  for  information  held  at  an  applications  process  to  be  distributed 
among  cooperating  systems. 

•  Address  database  issues  such  as  data  integrity  and  consistency,  together  with 
replication  of  data. 

•  Identify  constraints  on  process  decomposition  and  interaction  types  (communication 
among  subprocesses). 

•  Specify  distributed  application  support  for  configuration  management,  reconfiguration, 
and  routing. 

•  Define  application  features  to  allow  migration  for  future  extensions. 

•  Address  real-time  effects  associated  with  distribution. 

•  Provide  for  time  synchronization  of  application  processes. 

However,  true  distributed  applications  have  yet  to  be  achieved  since  the  network  is  not 
hidden.  A  promising  tool  in  this  area  is  the  RPC  tool  (see  Section  9.11.3.5),  which  allows 
applications  at  run-time  to  move  from  one  transport,  such  as  TCP/IP,  to  another  such  as  OSI. 
[Ref.  OSN  1990c] 

Within  IEEE,  the  Distributed  Services  Steering  Committee  has  oversight  and  coordination 
of  all  distributed  services  working  groups. 

13.1  Distributed  Computing  Requirements  and  Services 

13.1.1  Requirements  for  Distributed  Computing 

Data  Management  Data  management  requirements  for  distributed  information  systems, 
derived  from  ISO  10032,  Reference  Model  on  Data  Management,  are  defined  in  Section  6.1.2. 

Client/Server  Capabilities.  Distributed  information  systems  will  make  use  of 
client/server  capabilities,  and  these  capabilities  are  the  subjects  of  many  emerging  standards.  The 
Programming  Language  SQL  (ISO  9075:1992)  introduced  the  terms  client  and  server  as  a  basis  for 
distinguishing  capabilities  of  an  SQL  implementation,  and  the  current  standard  for  SQL 
specialization  for  remote  database  access  (RDA)  uses  the  terms  client  and  server  for  communicating 
components  that  support  access  from  an  application  process  to  a  remote  SQL  implementation. 
There  are  alternative  ways  in  which  these  capabilities  may  be  combined  and  these  may  need  to  be 
standardized.  For  example,  access  to  a  remote  IRDS  can  use  either  an  RDA-based  communication 
or  a  remote  procedure  call  (RPC)-based  communication.  In  addition,  ODP  (see  Section  13.2)  and 
many  recommendations  cm  distributed  computing  environments  (see  Sections  13.3  to  13.5)  adopt 
the  client/server  paradigm.  SC21/WG3  has  proposed  a  question  (Q3/01 1)  on  harmonization  of 
client/server  capabilities,  which  would  address  requirements  for  client/server  capabilities,  need  for 
a  client/server  architecture,  and  potential  use  of  such  an  architecture  in  SC21  standardization 
activities.  [Ref.  SC21  N8019  1993] 

13.1.2  Distributed  Interactive  Simulation  (DIS) 

A  standard  on  Distributed  Interactive  Simulation  (DIS)  Protocol  Data  Units  (PDUs)  was 
developed  by  the  DIS  workshops  and  transmitted  to  the  IEEE  for  standardization.  It  deals  with 
application  protocols  for  distributed  simulation  of  battlefield  entities  that  are  controlled  by  humans 
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and  operating  in  real  time.  Information  such  as  type  of  weapons  platform,  country  of  origin, 
position,  velocity  vector,  munitions  and  fuel  status,  etc.,  are  described  by  the  PDU.  The  PDU  is 
the  sole  method  of  coordinating  interacting  entities.  This  standard  was  approved  in  March  1993. 

Current  work  is  in  developing  an  augmented  standard  in  which  environmental  effects  and 
electronic  warfare  are  more  fully  described.  Version  2  is  ready  for  submission  and  the  group  is 
ready  to  begin.  An  even  greater  variety  of  environmental  and  unit  representation  will  be  available 
in  Version  3. 

Companion  standards  for  terrain  and  other  common  environmental  databases  are  in  early 
versions  ready  for  submission  to  the  IEEE.  A  communication  profile  for  the  use  of  those 
transmitting  the  PDUs  between  distributed  hosts  is  also  ready  for  submission  in  late  1993.  A 
document  describing  exercise  control  and  feedback  requirements  is  in  preparation  for  submission 
in  1994.  A  document  concerning  fidelity  is  due  in  late  1994. 

13.2  Open  Distributed  Processing  (ODP)  Standards 

Open  Distributed  Processing  (ODP)  allows  both  users  and  applications  to  interact  remotely 
with  any  other  computational  resources  (including  other  applications)  held  at  different  locations.  A 
single  application  might  also  be  divided  into  sub-units  for  execution  in  parallel  on  a  number  of 
machines  linked  together  by  a  network.  In  its  most  sophisticated  form,  this  allows  multiple 
"clients"  (users  or  their  local  applications)  to  request  services  from  multiple  remote  "servers"  using 
various  software  protocols  such  as  a  Remote  Procedure  Call  (RPC)  to  achieve  the  required 
communications  and  synchronization.  [Ref.  OSN 199  lj] 

13.2.1  ODP  Standards 

ODP  is  a  new  area  of  standards  development  Begun  in  1987,  the  work  has  progressed  so 
far  in  ISO  that  a  new  working  group  (SC21/WG7)  was  formed  by  the  JTC1  to  progress  the 
standards  for  an  ODP  Reference  Model.  Moreover,  ODP  was  added  to  the  SC21  title  in  1993. 
The  current  work  comprises  the  framework  of  abstractions  (e.g.,  the  nature  of  die  different  points 
of  view  of  a  system);  functions  and  interfaces;  and  modelling.  It  addresses  the  following  aspects: 

•  Modelling  distributed  processing  in  terms  of  components,  the  services  they  support, 
their  environment,  and  the  interactions  between  them 

•  Identifying  levels  of  abstraction  at  which  the  services  and  interactions  can  be  described 

•  Classifying  the  boundaries  between  components  and  identifying  the  points  of 
interaction  associated  with  them 

•  Identifying  generic  functions  performed  by  distributed  systems 

•  Showing  how  the  elements  of  the  model  can  be  combined  to  achieve  ODP. 

The  Basic  Reference  Model  of  ODP  (CD  10746)  further  defines  levels  of  abstraction  at 
which  services  and  interactions  can  be  defined  in  other  standards,  generalizing  the  concepts  of 
service  and  protocol  defined  in  the  OSI  Reference  Model  (ISO  7498).  The  structure  of  the  Basic 
Reference  Model  is  as  follows: 

•  WD  10746-1  (Part  1):  Overview  and  Guide  to  Use,  containing  a  motivational 
overview  of  ODP,  giving  the  scope,  explaining  the  key  definitions  (with  no  substantial 
architectural  content),  and  enumerating  required  areas  of  standardization  (not 
normative) — CD  is  expected  July  1994,  DIS  in  January  1995,  and  IS  in  October  19%. 
Initiation  of  ITU-TS  ballot  approval  is  expected  in  19%.  The  most  recent  WD  is 
SC21  N  8218,  September  1993. 
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•  CD  10746-2.3  (Part  2):  Descriptive  Model,  defining  the  concepts,  analytical 
framework,  and  notation  for  normalized  description  of  (arbitrary)  distributed 
processing  systems  (not  normative  but  establishes  requirements  for  new  specification 
techniques) — Currently  in  third  CD  (10746-2.3)  [SC21  N  7988,  August  1993].  DIS 
is  expected  in  February  1994  and  IS  in  November  1995.  Initiation  of  ITU-TS  ballot 
approval  is  expected  in  June  1995. 

•  CD  10746-3.2  (Pari  3):  Prescriptive  Model,  specifying  the  required  characteristics  that 
qualify  distributed  processing  as  open — these  are  the  constraints  to  which  ODP 
standards  must  conform — This  major  revision  of  Part  3  has  added  a  set  of  viewpoint 
languages  that  can  be  used  to  define  an  ODP  system.  [Ref.  OSN  1992m]  (ITU-TS 
X.903)  Currently  in  second  CD  [SC21  N  8125,  August  1993].  DIS  is  expected  in 
February  1994  and  IS  in  November  1995.  Initiation  of  ITU-TS  ballot  approval  is 
expected  in  June  1995. 

•  WD  10746-4  (Part  4):  The  original  Part  4,  User  Requirements,  was  merged  with  Part 
1  in  June  1992  since  there  was  no  major  distinction  between  them  and  a  danger  of 
duplication  [Ref.  OSN  1992m].  Part  5.  Architectural  Semantics  (originally  entitled. 
Architectural  Semantics  for  FDTs),  is  now  Part  4 — CD  text  is  expected  July  1994, 
DIS  in  January  1995,  and  IS  in  October  19%.  Initiation  of  ITU-TS  ballot  approval  is 
expected  in  1996. 

Principles  for  the  specification  of  management  for  ODP  systems  are  now  being  integrated 
into  Pans  1  and  3  of  the  ODP  standard. 

13.2.2  Relation  of  (  *  to  Distributed  Database  Systems 

SC21/WG3  has  proposed  a  question  on  the  use  of  ODP  for  distributed  database  systems 
(see  Section  6.1.4).  The  basis  for  the  question  is  the  need  to  fit  distributed  database 
standardization  into  the  broader  context  of  a  framework  for  distributed  systems.  Specifically, 
requirements  for  distributed  database  systems  include  several  requirements  related  to  distribution 
transparencies  described  in  the  ODP  Reference  Model:  location,  fragmentation,  and  replication  of 
data;  and  the  way  data  management  services  may  be  distributed  to  support  these  requirements. 
Work  on  the  new  question  would  address  such  issues  as  how  the  ODP  Reference  Model  can  be 
used  to  provide  an  architecture  for  the  description  of  processing  relevant  to  distributed  database 
systems,  which  distributed  processing  functions  can  be  used  to  support  requirements  of  distributed 
database  systems,  what  additional  functions  are  required,  and  in  what  ways  such  functions  require 
support  of  data  management  services.  [Ref.  SC21/WG3  N  1557  Rev  1993] 

13.2.3  ODP  Specification  Techniques 

Use  of  Specification  Techniques  in  ODP  is  a  new  draft  technical  report  split  off  from  earlier 
work  on  CD  10746.  This  technical  report  defines  requirements  on  specification  techniques  for 
ODP  and  evaluates  standardized  formal  description  techniques  (FDTs)  against  these  requirements. 
The  formalization  of  modelling  concepts,  provided  by  a  mapping  to  the  concepts  of  each  FDT,  acts 
as  a  bridge  between  the  ODP  architecture  and  FDTs. 

ISO/ITU-TS  Joint  Modelling  Group  has  proposed  the  abstract  specification  language  Z  as  a 
candidate  FDT  for  use  in  ODP  [SC21  N  6088].  In  January  1992,  a  proposal  for  a  new  question 
(Q7/1 )  on  the  suitability  of  the  FDT  Z  for  use  in  ODP  was  accepted  [SC2 1  N  6674].  The  proposed 
draft  answer  to  Q7/1  states  that  conventional  Z  meets  many,  but  not  all  of  ODP  requirements. 
However,  it  is  amenable  to  extensions  to  include  object-oriented  concepts,  which  many  meet  most 
of  ODP  requirements.  Therefore,  should  a  NWI  on  the  standardization  of  Z  be  accepted,  object- 
oriented  extensions  will  be  necessary.  [Ref.  SC21  N  7051  1992]  The  Trader  Rapporteur  Group 
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has  agreed  to  adopt  the  Z  notation  for  use  in  the  information  specification  of  the  ODP  Trader, 
specifically  the  formalization  of  the  information  objects  and  their  relations.  [Ref. 
SC21/WG7  N  737  1992 

ODP  Standardization  Activities.  The  approach  of  SC21/WG7  has  been  to  identify 
and  expand  a  number  of  ODP  topics  in  parallel.  The  applicable  documents  are: 

•  Topics  lust— November  1989  Version— for  the  Basic  Reference  Model  of  Open 

Distributed  Processing,  December  1989  [SC21 N  4019] 

•  Topic  1 — The  Problem  of  Distributed  Processing,  March  1988  [SC21 N  2507] 

•  Topic  2.2 — Properties  and  Design  Freedoms,  December  1988  [SC21  N  3288] 

•  Topic  2.3 — Framework  of  Abstractions,  December  1988  [SC21  N  3194] 

•  Topic  3— Structure  of  ODP  Standards,  March  1988  [SC21 N  2509] 

•  Topic  4.1 — Functions  and  Interfaces,  December  1989  [SC21 N  4022] 

•  Topic  4.3 — Function  and  Interface  Definitions  [SC21 N  6081] 

•  Topic  5.1 — Modelling  Techniques  and  Their  Use  in  ODP,  December  1989 
[SC21  N  4023] 

•  Topic  6.2 — Formalisms  and  Specification,  December  1989  [SC21 N  4024] 

•  Topic  7.1— Basic  RM  of  ODP,  December  1989  [SC21 N  4029] 

•  Topic  8.1— Draft  Basic  RM  of  ODP,  Part  D,  December  1989  [SC21  N  4025] 

•  Topic  9.1— ODP  Trader,  June  1992  [SC21  N  7047] 

•  list  of  Open  and  Resolved  Issues— June  1992  Version,  June  1992  [SC21  N  7057]. 

The  open  issues  are: 

•  Issue  2:  What  should  the  working  definition  of  ODP  System  be? 

•  Issue  7:  How  is  the  conceptual  schema  communicated? 

•  Issue  11:  What  should  the  human  interface  function  be? 

•  Issue  17:  What  are  the  principle  abstractions  associated  with  each  of  the  five 
viewpoints? 

•  Issue  23:  What  is  the  scope  of  an  ODP  enterprise? 

•  Issue  24:  What  is  the  WG7  position  on  modelling,  specification  use,  and  roles  of 
conceptual  schemas? 

•  Issue  25:  How  should  translations  from  ASN.l  to  ODP/DAF-sekcted  FDTs  be 
developed  and  should  WG7  undertake  this  task? 

•  Issue  26:  Is  the  notion  of  event  needed  in  basic  concepts  of  Part  2? 

•  Issue  27:  What  are  the  relationships  between  interface,  interaction  point,  and 
binding? 

•  Issue  28:  What  are  the  definitions  of  behavioral  compatibility  and  refinement? 

•  Issue  29:  Are  data  elements  objects? 

•  Issue  30:  Can  alternative  definitions  for  a  function  be  given  within  a  single 
viewpoint? 

•  Issue  31:  Is  the  initiate  operation  part  of  the  trading  function? 

In  November  1990,  Australia  proposed  a  new  work  item  to  develop  a  standard  entitled: 
ODP  Trader  — A  Standard  to  Define  the  Role  and  Function  of  the  Trader  in  Open  Distributed 
Processing  (ODP)  [ISO/IEC  JTC1/SC21  N  5564,  January  1991].  This  NWI  was  accepted  into  the 
JTC1  work  program  in  April  1992.  The  most  recent  WD  on  ODP  Trader  is  SC21  N  8192  dated 
August  1993.  CD  text  is  expected  in  July  1994,  DIS  in  December  1995,  and  IS  in  July  1997. 
Initiation  of  ITU-TS  ballot  approval  is  expected  in  1996.  The  Trader  is  a  component  of  an  ODP 
system  that  supports  trading  interactions  (a  trader  is  defined  to  be  an  object  to  which  an  exporting 
object  can  advertise  its  services  and  from  which  an  importing  object  can  find  its  needs  from  the  set 
of  advertised  service  offers  in  a  distributed  environment).  [Ref.  SC21/WG7  N  783  1993].  The 


Chapter  13 


299 

UNCLASSIFIED 


Distributed  Computing 


UNCLASSIFIED 


document  will  include  a  nonnative  annex  on  use  of  Directory.  The  ODP  Trader  standard  is  needed 
to  ensure  [Ref.  SC21  N  6085  1991]: 

•  Portability  of  applications  in  an  ODP  environment 

•  Internetworking  between  ODP  systems 

•  Distribution  transparency  in  ODP  systems. 

The  following  lists,  in  priority  order,  the  Trader  work  plan  [Ref.  SC21/WG7  N  737  1992]: 

•  Information  specification  of  the  Trader 

Administrative  control  over  construction  and  assessment  of  trading  context 
structure  (search  policies,  use  of  QoS  in  search  policies,  context  membership 
rules) 

Matching  rules 
Selection  criteria 
Z  specification 

•  Computational  specification  of  the  Trader 

Operation  Definitions 

IDL  specification  of  operations  and  parameters 
Specification  of  behavior 

Naming  of  service  types,  trading  context,  service  offers 

•  Issues  in  Enterprise  Specification 

Federating  with  Federation  -  the  significance  of  uplinking  and  downlinking 

•  Conformance  statements 

•  Relationship  to  X.500  and  WG3  Database  Management 

•  Relationship  of  Trader  to  other  components 

Type  Management 
Security  Model 
Accounting  Model. 

A  recent  WG7  working  document  (SC21/WG1  N  1253,  May  1993)  discusses  the  issues 
involved  in  specifying  the  QoS  (see  Section  12.1.6)  so  that  they  can  be  used  in  trading  services 
(ODP  Trader). 

In  the  absence  of  an  Editor  and  progression  of  the  WD,  an  ODP  project.  Use  of 
Specification  Techniques  in  ODP  Semantics,  is  under  reassessment  by  SC21.  [Ref.  SC21  N  7728 
1993] 

Further,  SC21  has  proposed  a  new  question  on  the  relationship  between  the  OSI  Upper 
Layer  Architecture  (ULA,  see  Chapter  9)  and  ODP.  This  question  has  beat  accepted  into  the  JTC1 
work  program  [SC21  N  6609,  6  December  1991].  The  draft  answer  states  that  ODP  and  OSI 
upper  layers  modelling  activities  differ  in  their  respective  scopes.  While  the  RM-ODP  provides  a 
framework  for  the  standardization  of  all  aspects  of  distributed  processing  systems,  the  OSI 
Application  Layer  Structure  addresses  the  modelling  needs  of  distributed  applications  from  a 
communications  perspective.  [Ref.  SC21  N  6972  1992] 

ITU-TS  Group  VII  has  proposed  a  question  (Q16/VII)  for  the  1993-1996  Study  Period  that 
would  continue  the  work  of  Q19/VII  in  the  area  of  ODP.  The  question  asks  what  new 
Recommendations  are  needed  to  [Ref.  SC21  N  6956  1992): 

•  Establish  a  set  of  modelling  concepts  to  support  a  RM-ODP 

•  Detail  the  RM-ODP 

•  Specify  an  ODP  Trader  for  use  by  ITU-TS  applications. 
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In  June  1992,  a  new  question  (Ql/66)  on  ODP  Conformance  Testing  Methodology  was 
proposed.  Specifically,  if  focuses  on  what  needs  to  be  done  to  develop  an  ODP  conformance 
testing  methodology  in  ISO/IEC  9646  building  on  the  concepts  of  ODP  conformance  described  in 
the  ODP  Basic  Reference  Model.  [Ref.  SC21  N  7088  1992]  The  results  of  the  ballot  indicate  that 
the  majority  of  the  National  Bodies  voting  support  work  on  the  proposed  new  question.  WG1 
began  work  in  June  1993.  [Ref.  SC2 1  N  7476  1992] 

13.3  Object  Management  Group  (OMG) 

The  Object  Management  Group  (OMG)  (see  Appendix  F)  is  a  consortium  of  over  340 
companies,  educational  institutions  and  governmental  organizations  that  wish  to  establish  de  facto 
standards  for  the  use  of  an  object-oriented  model  of  distributed  computing.  The  group  issues 
requests  for  technology  based  on  specifications  that  its  working  groups  develop. 

The  OMG  does  not  develop  products  other  than  specifications.  To  date  the  OMG  has 
issued  an  Object  Architecture  Guide  and  a  specification  for  the  Common  Object  Request  Broker 
Architecture  (CORBA),  which  is  currently  in  Version  1.1.  Products  using  or  based  on  CORBA 
are  now  available,  and  OMG  is  developing  a  CORBA  catalog  of  vendor  implementations  and 
applications  using  CORBA.  [Ref.  Stone  1993] 

CORBA  is  one  part  of  the  Object  Management  Architecture  (OMA)  defined  by  the  OMG. 
CORBA  specifies  the  concept  Object  Request  Brokers  (ORB),  which  defines  how  a  set  of 
interworking  classes  and  instances  interact.  An  ORB  provides  an  infrastructure  allowing  objects  to 
communicate,  independent  of  the  specific  platforms  and  techniques  used  to  implement  the 
addressed  objects,  guaranteeing  interoperability  of  objects  over  a  network  of  non-homogeneous 
systems.  Together  with  Object  Services,  Common  Facilities,  and  Application  Objects,  the  (BIB 
forms  (me  of  the  four  major  parts  of  an  OMA.  COBRA  includes  a  core  communications 
infrastructure  and  a  set  of  Object  Adapters  for  different  object  implementations.  COBRA  permits 
client  access  services  and  object-references  to  be  realized  either  through  stubs  generated  from  an 
interface  definition  language  or  through  a  dynamic  APL  [Ref.  RNLA  1994,  pp.  34-42] 

A  second  revision  of  CORBA  (2.0)  to  fix  problems  of  interoperability  and  interface 
repository  federation  is  underway.  Currently,  only  a  C  mapping  to  the  Object  Request  Broker 
(ORB)  is  specified.  A  C++  mapping  is  about  to  be  selected;  Smalltalk  and  COBOL  mappings  will 
be  selected  next  year,  as  will  an  upgraded  interface  repository  interface.  The  ISO  ODP  group  is 
working  to  progress  this  work  in  their  committee  as  a  basis  for  their  standards. 

OMG  is  working  on  a  revision  of  the  Object  Model  document  based  on  its  experience  with 
the  ORB.  It  currently  has  issued  a  request  for  proposal  on  a  collection  of  Object  Services  to  be 
used  with  the  ORB  and  a  roadmap  for  the  implementation  of  these  services. 

During  the  last  half  of  1993,  OMG  planned  to  procure  life-cycle,  naming,  persistence,  and 
event  notification  services.  In  the  first  half  of  1994,  OMG  wants  to  procure  relationship, 
transactions,  and  concurrency  control  services.  In  the  last  half  of  1994,  OMG  wants  to  procure 
two  packages  of  services.  The  first  package  includes  security  service,  ‘‘exteriorization,”  data 
interchange,  licensing  service,  and  trading  service.  The  second  package  includes  query,  change 
management,  and  properties  services. 

Additional  services  are  specified  in  the  Object  Services  Architecture.  These  services  fall 
into  two  categories:  (1)  CORBA-related  services,  which  include  the  interface  repository  and  the 
implementation  repository,  and  (2)  system-related  services.  The  Object  Services  Task  Force 
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(OSTF)  feels  that  the  CORBA-related  services  will  be  dealt  with  by  either  the  ORB  2  Task  Force  or 
the  OSTF.  The  set  of  system  related  services  were  not  of  the  highest  priority  but  may  be  dealt  with 
by  OSTF  at  a  later  time.  They  include  such  services  as  archive,  backup,  startup,  installation  and 
activation,  operational  control,  replication,  object  threads,  and  time. 

OSF,  Ul,  and  X/Open  all  have  endorsed  the  OMG  and  its  ORB  in  particular.  OSF  and  UI 
plan  to  provide  a  version  of  the  ORB  in  the  "near  future."  Hyperdesk  and  Hewlett  Packard  offer 
ORB  toolkits  today.  In  February  1993,  the  OMG  requested  a  liaison  with  ISO/IEC  JfTCl 
SC21/WG7.  (Ref.  SC21  N  7613  1993]  The  SC21  response  was  favorable  and  included  a  paper 
[Ref.  SC21  N  8034  1993]  that  compares  ODP  and  OMG  architectures.  The  goal  of  the  paper  was 
to  serve  as  a  basis  for  converging  the  two  architectures  so  that  the  OMG  specifications  can  become 
potential  candidates  for  fast-track  adoption  by  ISO,  to  fulfill  the  requirements  for  ODP  functions  as 
identified  in  ODP-RM-3  (CD  10746-3).  Potential  candidates  for  early  use  in  ODP  included  in  the 
comparison  were  COBRA,  persistence,  life-cycle  service,  event  service,  and  name  service. 
Candidates  for  later  use  in  ODP  were  transaction,  concurrency  control,  time,  relationships,  and 
extemalization  services. 

13.4  Open  Software  Foundation  (OSF) 

The  Open  Software  Foundation  (see  also  15.1.2.4  and  Appendix  F)  is  a  consortium  of 
over  360  members  including  commercial,  government,  and  university  groups.  It  is  a  technology 
integrator  and  distributor  of  Open  Systems  Technology  with  over  300  employees  worldwide.  Its 
technology  products  include  an  operating  system,  OSF/1  Release  1.2  (see  Section  10.2.2);  a  visual 
user  interface  and  toolkit.  Motif  1.2  (see  Section  5.2.7);  and  a  distributed  computing  environment, 
DCE  1 .0.2  A.  Products  in  progress  include  components  of  a  distributed  management  environment 
(DME).  Research  at  the  OSF  Research  Institute  is  leading  to  a  neutral  distribution  format  (ANDF) 
methodology  (see  Section  15.1.3.5)  for  distributing  portable  software  and  a  microkernel  (Mach) 
(see  Section  10.2.2)  on  which  later  versions  of  UNIX  can  be  based. 

13.4.1  Distributed  Computing  Environment  (DCE) 

The  OSF  DCE73  contains  a  number  of  subsystems  designed  to  extend  UNIX  functionality. 
The  reference  version  of  DCE  is  available  for  OSF/1.  User-contributed  versions  are  available  for 
UNIX  SVR4  (from  Siemens).  (Note:  clients  for  the  PC  have  been  done  by  Gradient  Technology 
for  Windows  and  by  IBM  for  OS/2  Release  2.x).  Versions  are  also  available  from  manufacturers 
running  on  a  wide  variety  of  platforms  and  operating  systems.  DCE  provides  the  following: 

•  A  threads  library.  This  library  permits  the  development  of  multi-threaded  applications, 
essential  to  development  of  servers.  According  to  OSF,  this  library  corresponds  to 
POSIX  P1003.4a  (draft  4). 

•  A  remote  procedure  call  facility  and  toolkit  based  on  work  of  Hewlett-Packard  (HP) 
and  Apollo's  NCS  version  of  remote  procedure  call  (RPC).  This  is  the  mechanism 
that  permits  authenticated  interaction  between  heterogeneous,  distributed  client 
programs  and  server  programs. 

•  A  network  time  protocol  (NTP)  developed  by  Digital  Equipment  This  provides  a 
provable,  bounded  time  over  an  arbitrary  network.  It  is  a  requirement  for  the 
authentication  scheme  used  in  DCE. 
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•  An  authentication  service  based  on  Kerberos  S.O  from  the  Athena  project  at  MIT  and 
improved  by  Hewlett  Packard.  This  service  provides  certification  of  identity  to  those 
services  that  requite  it 

•  A  scaleable  set  of  distributed  file  services  derived  from  the  Carnegie  Mellon  University 
ANDREW  project  and  commercialized  by  the  TRANSARC  Corporation.  This  file 
system  is  designed  to  run  with  a  satisfactory  performance  over  wide  area  networks 
(WANs). 

•  Directory  services,  including  a  local  directory  service  for  the  smallest  administrative 
level  or  cell  level  (CDS)  provided  by  Digital  Equipment  and  a  global  directory  service 
compatible  with  the  X.500  standard  provided  by  Siemens.  These  services  allow 
transparent  file  reference  across  multiple  distributed,  heterogeneous  platforms. 

•  A  product  permitting  distributed  transaction  based  computing  based  on  the  Camelot 
transaction  system  from  Carnegie  Mellon  University  and  commercialized  by 
TRANSARC  Corporation  under  the  name  ENCINA. 

•  A  set  of  products  promoting  PC  integration  including  Microsoft's  LAN  Manager  and 
Locus'  PC  Interface  program. 

OSFs  DCE  has  been  widely  implemented  or  is  in  the  plan  of  most  major  manufacturers  of 
Open  Systems.  It  is  installed  in  over  1,200  sites.  OSF  has  compiled  a  catalog  of  more  than  70 
products,  including  DCE  implementations  as  well  as  DCE-enabled  tools  and  applications.  The 
bulk  of  these  products  are  currently  available,  with  the  rest  planned  for  1994  delivery.  DCE  has 
been  accepted  by  X/Open  and  UNIX  International,  de-facto  standard  setters  for  industrial  open 
systems.  It  will  form  part  of  the  base  for  COSE. 

13.4.2  Distributed  Management  Environment  (DME) 

The  DME  is  designed  to  be  layered  on  top  of  DCE  regardless  of  the  manufacturer  or  system 
software.  It  consists  of  a  number  of  parts  to  be  delivered  in  three  phases.  Phase  1  consists  of  a 
Software  Distribution  Service  (SDS),  License  Management  Service  (LMS),  Event  Service  (EVS), 
Subsystem  Management  Service  (SMS),  and  PC  Services  (PCS).  Phase  2  consists  of  a  Print 
Management  Service  (PRS).  Phase  3  consists  of  a  management  framework. 

Phase  1  of  DME.  The  software  distribution  service  provides  for  the  delivery, 
maintenance,  and  update  of  software  using  network  resources.  This  is  particularly  useful  in  large 
environments.  The  original  technologies  were  from  HP  and  IBM. 

The  license  management  service  will  provide  a  standard  infrastructure  that  will  permit 
software  to  be  used  on  a  license  available  basis.  In  this  practice,  a  pool  of  licenses  is  established 
for  the  cell.  Individual  licenses  may  be  obtained  from  the  pool  by  any  authorized  user. 
Presentation  of  the  license  gains  use  of  the  software.  When  the  use  of  the  software  is  finished,  the 
license  may  be  made  available  for  another  user.  The  original  components  were  from  HP  and 
Gradient  Technologies. 

The  event  service  makes  possible  the  communication  of  network  and  system  events  to 
users  on  other  parts  of  the  distributed  computing  resource.  Emergencies  such  as  paper  outage, 
requests  such  as  for  media  mounting,  and  announcements  such  as  routine  maintenance  schedules 
may  be  handled  uniformly  by  the  event  service.  The  original  technologies  were  from  Wang  Labs. 

Subsystem  management  service  permits  a  user  to  administer  individual  components  of  the 
cell  from  authorized  locations  in  the  physical  network,  and  to  manage  heterogeneous  systems  a 
uniform  manner.  For  example,  platforms  and  servers  may  be  started  or  shutdown. 
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PC  Services  permit  invocation  of  and  communication  with  services  available  in  the 
computing  environment  from  an  MS-DOS  machine  and  use  the  minimal  resources.  These 
components  were  developed  by  Gradient  Technologies.  Phase  1  began  shipping  as  of  mid- 
November  1993  as  DME  1.0. 

Phase  2  of  DME:  Print  Services.  The  print  services  are  used  by  management  and 
user  applications  to  print  and  control  the  use  of  printing  resources.  The  printer  supervisor  and 
spooler  use  the  ISO  10175  DPA  protocol.  The  printing  systems  program  interface  is  used  as  the 
base  for  the  POSIX  printing  management  standard.  These  components  were  originated  at  Project 
Athena  at  MIT  and  adapted  by  DEC.  Delivery  is  expected  in  the  second  quarter  of  1994. 

Phase  3  of  DME:  The  Management  Framework.  The  management  framework  is 
most  comprehensive.  Originally  provided  by  Tivoli  Systems  and  Bull,  S.A.  of  France,  this 
framework  was  to  have  managed  network  assets  utilizing  SNMP  and  TCP/IP  protocols  as  well  as 
CMIP  and  OS1  protocols  in  a  manner  transparent  to  the  user.  With  the  advent  of  the  Object 
Management  Group's  Common  Object  Request  Broker,  the  management  framework  was  recast  to 
use  the  new  technology  with  IBM's  help  in  rewriting  the  Tivoli  interfaces.  A  standard  user 
interface  for  management  applications  is  also  provided. 

13.5  Other  Distributed  System  Standardisation  Initiatives 

13.5.1  Message-Oriented  Middleware  Consortium  (MOM) 

The  Message-Oriented  Middleware  Consortium  (MOM)  [Ref.  Stahl  1993]  is  a  new 
middleware-vendor  association.  MOM  promotes  middleware  that  uses  messaging  technology  to 
allow  applications  to  communicate  across  distributed  platforms.  Consortium  members  include 
Digital  Equipment,  IBM,  and  Covia  Technologies. 

Middleware  has  been  variously  defined  as: 

•  Technology  that  shields  applications  from  underlying  network  protocols  and  operating 
systems; 

•  Technology  that  allows  users  to  access  multiple  databases  without  knowing  the 
intricacies  of  each;  and 

•  Software  that  sits  between  client  and  server  in  a  distributed  computing  environment 

There  are  several  types  of  middleware  including  application  programming  interfaces  (APIs) 

(see  Section  15.2),  remote  procedure  calls  (RPC)  (see  Section  9.1 1.3.5),  network  messaging  (see 
Section  9.1 1.4),  database  access  (see  Section  6.2.2.2),  and  computer-aided  software  engineering 
(CASE)  tools  (see  Section  4.3.2).  The  intent  of  the  consortium  is  to  create  standards  in  messaging 
middleware. 

13.5.2  Multinational  Projects  in  Europe 

In  parallel  to  various  industry  initiatives  in  distributed  systems,  such  as  DCE  and  COBRA, 
there  has  been  considerable  effort  spent  on  distributed  systems.  These  include  the  following  (in 
Europe)  [Ref.  RNLA  1994,  pp.  51-52]: 

•  Advanced  Networked  Systems  Architecture  (ANSA) — initiated  as  an  Alvey  project  in 
the  United  Kingdom  and  continued  in  the  ESPIRIT  project  ISA.  ANSA  defines 
several  aspects  of  a  distributed  object-based  architecture,  including  a  computational 
model  (the  fundamental  object  model),  a  naming  model  (for  naming  objects  in  a 
distributed  system),  a  model  for  interface  groups  (for  object  replication),  an 
engineering  model  (with  proposed  implementation  structures),  an  approach  to  currency 
control,  a  programming  language,  and  a  (partial)  implementation. 
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•  ESPIRIT  ISA — promotes  ISO  ODP  and  has  developed  an  evaluation  chassis 
(AnsaWare)  for  ODP.  Ansa  Ware  is  not  yet  directly  compatible  with  OSFs  DCE  or 
DME,  UI  Mas,  or  COBRA. 

•  ESPRIT  COMMANDOS  (now  inactive) — investigated  tools  and  services  for  an 
advanced  object-based  distribution  platform,  including  database  integration,  which  led 
to  a  number  of  prototypes. 

•  ESPIRIT  Harness — merges  technology  results  into  a  common  architecture  and  a 
prototype,  with  the  goal  of  integration  with  a  DCE  snapshot 

•  ASSET — a  project  (Advanced  System  and  Software  Engineering  Enabling 
Technologies)  of  Bull,  Olivetti,  and  Siemens-Nixdorf,  with  a  goal  of  establishing  a 
European  Development  Environment  for  Open  Distributed  Systems  based  on  COBRA 
and  results  from  COMMANDOS  and  ISA/Hamess. 

•  Eureka  Software  Factory  (ESF> — a  project  to  make  a  factory  environment  for 
developing  software  that  is  adaptable  to  different  organizations  and  application  areas, 
carried  out  by  a  consortium  of  14  different  companies  in  five  European  countries. 
ESF  is  based  on  a  “software  bus”  that  defines  interactions  among  software 
components  (much  as  a  hardware  bus  does  for  hardware  components)  and  provides  a 
unique  global  environment  by  encapsulating  heterogeneous,  interoperating  systems 
within  a  common  interface.  Its  work  has  addressed  control  integration  (software  bus), 
presentation  integration  (user  interface  building  tools),  data  integration  (object  storage 
services),  and  work-process  integration  (process  modelling  support): 

•  CADDIE — a  software  environment  supporting  design  and  implementation  of  dynamic 
and  distributed  multi-agent  decision  systems  and  control  hierarchies  with  an  open 
architecture  based  on  object-oriented  design  and  intended  to  conform  to  emerging 
standards  in  object-oriented  programming  and  knowledge  representation.  One  of  the 
largest  multi-agent  systems  developed  to  date  using  commercially  available  tools, 
CADDIE  was  partially  funded  by  the  UK  Department  of  Trade  and  Industry. 

13.5.3  Decision  Support  and  Knowledge  Engineering 

Decision  Support  Architectures.  A  promising  architecture  for  decision  support 
systems  is  a  multi-agent  architecture  based  on  a  blackboard  data  structure,  whose  key  components 
are  the  agents  and  the  blackboards.  Agents  me  composed  of  knowledge  sources  that  contain 
information  about  a  specific  action  the  agent  can  perform.  A  control  mechanism  is  needed  in  order 
to  cany  out  the  planning  process,  since  several  agents  can  execute  simultaneously  trying  to  achieve 
different  goals.  Such  agents  communicate  with  each  other  using  the  blackboards.  More  than  one 
planner  method  (strip  or  hierarchical)  can  be  implemented  with  this  architecture.  Use  of  the 
blackboard  data  structure  allows  a  neat  implementation  of  the  events  as  simple  changes  in  the 
objects  of  the  blackboard.  Support  of  concurrent  operations  from  a  multitasking  operating  system 
and  use  of  real-time  tasking  services  is  desired.  These  would  support  the  range  of  tasks,  both 
periodic  and  nonperiodic,  associated  with  C3I  applications,  with  time  deadlines  working 
concurrently  within  the  system  and  with  large  amounts  of  incoming  data  that  needs  to  be  processed 
quickly.  [Ref.  RNLA  1994,  pp.  286-287] 

Advanced  Technology  Operations  System  (ATOS).  ATOS  uses  results  of  the 
DARPA  Knowledge  Sharing  Effort  (e.g..  Knowledge  Query  and  Manipulation  Language  and 
Knowledge  Interchange  Format)  to  specify  communications  between  applications  with  respect  to  a 
shared  model  (ontology),  which  defines  concepts  and  terms  that  the  applications  use  to  exchange 
domain  information.  Work  on  ATOS  is  being  carried  out  by  a  consortium  consisting  of  Logica 
Space,  Communications  Limited,  Space  Application  Services,  and  GMV.  It  addresses 
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development  of  mechanisms  to  enable  translation  between  knowledge  bases  represented  in 
different  languages,  common  versions  of  languages  within  families  of  representation  paradigms, 
protocols  for  communication  between  knowledge-based  modules,  and  libraries  of  ontologies  that 
contain  skeletal  application-specific  knowledge  bases  in  particular  domains.  [Ref.  RNLA  1994] 

ATOME-TR.  ATOME-TR  is  a  project  that  provides  a  development  environment  for 
prototyping  complex  applications  as  a  parallel  “blackboard”  system  on  a  single  processor 
workstation.  In  the  blackboard  model,  three  types  of  agents  interact:  the  strategy  knowledge 
source  that  coordinates  the  overall  activity  of  the  system,  the  task  knowledge  sources  that 
coordinate  local  activities,  and  the  specialist  domain  knowledge  sources  that  infer  hypotheses  in  the 
blackboards.  ATOME-TR  implements  a  real-time  control  model  based  on  reactive  planning  in 
order  to  control  all  the  agents  according  to  temporal  deadlines  and  to  implement  approximate  or 
progressive  reasoning  with  real-time  constraints.  This  project  is  conducted  by  a  consortium  of 
Matra  Defense,  Matra  Cap  Systemes,  and  CRIN/INRIA  Lorraine  research  laboratory  in  France, 
with  support  from  the  French  MOD  (DRET)  and  the  French  Ministry  of  Research  and  Technology. 
[Ref.  RNLA  1994] 

13.5.4  National  Information  Infrastructure  Testbed  (NIIT) 

The  National  Information  Infrastructure  Testbed  (NUT)  is  a  consortium  of  representatives 
from  US  industry,  academia,  and  government  that  was  formed  in  September  1993  to  leverage  the 
National  Information  Infrastructure  (Nil)  vision  and  principles.  NUT  will  implement  the  vision  of 
the  NU  through  the  development  of  distributed  applications  requiring  the  speed  and  transmission 
capacity  of  a  true  data  superhighway  system.  Digital  is  among  the  members  of  the  NUT,  which 
will  be  standards  based.  [Ref.  OSS  1993] 

13.5.5  Applications  Peer-to-Peer  Network  (APPN) 

Cisco,  Founder  of  the  APPI  (Applications  Peer-to-Peer  Interface)  Forum  has  recently 
shifted  its  efforts  away  from  APPI,  which  was  to  network  IBM  systems  over  the  Internet's  IP 
protocol  and  has  licensed  IBM's  APPN  peer-to-peer  networking  protocol.  Although  the  APPI 
goal  was  technically  feasible,  to  build  it  without  use  of  IBM-patented  technology  would  require 
"work-arounds''  that  would  not  have  enough  functionality  to  fulfill  users'  needs.  Cisco  claims  that 
APPI  has  nevertheless  forced  IBM  into  dealing  more  openly  with  the  industry.  IBM  has  set  up  an 
APPI  Implementor's  Workshop  (AIW),  which  shares  developments  with  users  and  vendors, 
published  the  APPN  specifications,  and  licensed  the  patents.  [Ref.  OSN  1993s] 

13.5.6  System  Object  Model  (SOM) 

IBM  has  used  a  System  Object  Model  (SOM)  as  the  basis  of  its  emerging  distributed  object 
computing  environment.  SOM  permits  objects  to  be  defined  using  a  variety  of  languages,  using  a 
common  binary  format  for  object  classes  that  will  be  shared,  and  providing  bindings  to  C  and 
C++.  SOM  also  allows  object-oriented  software  to  be  packaged  and  shipped  as  binary  object  class 
libraries  (e.g.,  it  allows  object  classes  to  be  packaged  for  Windows  and  OS/2  and  as  shared 
libraries  for  AIX).  SOM  is  both  an  architecture,  defined  by  an  API,  and  a  runtime  environment 
SOM  includes  a  COBRA-compliant  interface  definition  language  (IDL)  compiler  used  to  write  class 
declarations;  a  call-level  API;  language  bindings  for  C  and  C++;  base  classes;  an  interface 
repository,  which  is  a  framework  to  provide  runtime  access  to  all  information  contained  in  the  IDL 
description  of  a  class;  and  Distributed  SOM  (DSOM),  which  is  a  framework  that  supports 
transparent  access  to  remote  objects  and  which  supports  both  the  static  and  dynamic  COBRA 
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APIs.  DSOM  is  an  extensible  ORB,  permitting  developers  to  add  their  own  methods.  Currently, 
DSOM  interfaces  to  communications  services  using  Berkeley  Sockets  and  supports  TCP/IP  on 
AIX;  and  TCP/IP,  NetBIOS,  and  IPX  on  OS/2.  Future  versions  of  SOM  are  planned  to  work 
with  the  DCE  and  make  use  of  the  DCE  RPC,  its  location  service,  and  its  security  service.  [Ref. 
'RNLA  1994,  pp.  42-43] 

13.6  Assessment  of  Open  Distributed  Computing 

The  effort  that  OSF  has  put  into  DCE  is  beginning  to  mature.  The  technology  will  be 
widely  available  in  the  first  half  of  1994.  Most  major  open  systems  vendors  will  offer  a  version 
interoperable  with  the  others  on  their  UNIX-based  systems.  Many  will  also  feature  DCE  ports  on 
their  proprietary  systems,  for  example  IBM's  OS/2.  SUN  and  Microsoft  may  be  the  only 
exceptions;  however  TRANSARC  will  provide  a  version  for  Solaris  and  Gradient  Technologies 
will  provide  a  version  for  Microsoft  Windows. 

In  terms  of  de  facto  standardization,  UNIX  International  has  promised  to  provide  DCE 
compatibility  in  the  near  future;  Siemens  already  provides  a  SVR4  version  of  DCE  as  an  OSF 
Reference  Model  X/Open  is  "fast-tracking"  DCE  for  incorporation  into  its  next  version  of  XPG. 
After  being  "standardized”  by  X/Open  and  adopted  by  the  open  system  vendors,  actual  ISO  or 
ANSI  standardization  is  expected. 

The  current  version  of  DCE  appears  to  be  usable  for  unclassified  purposes.  Care  must  be 
exercised  if  it  is  to  be  used  for  classified  purposes.  The  next  year  will  see  the  definition  of  a 
generalized  security  API  for  DCE  that  will  aid  the  implementor  in  developing  applications  that  deal 
with  classified  data.  Few  applications  utilizing  DCE  exist  Developer  kits  and  the  standardization 
of  the  application  environment  will  help  to  provide  the  impetus  so  that  applications  using  the 
interfaces  should  begin  to  appear  late  in  1994. 

One  of  the  most  demanding  application  suites,  the  Distributed  Management  Environment 
1.0  has  just  been  released  to  vendors.  DME  must  still  be  tailored  to  the  DCEs  of  individual 
manufacturers.  Printing  services  and  their  management  will  not  be  provided  until  the  spring  of 
1994.  The  management  framework  is  not  due  until  late  in  1994  or  early  in  1995.  Complete 
management  services  based  on  an  integrated  set  of  services  from  DCE  and  DME  are  not  likely  until 
mid- 1995  at  the  earliest 

Integration  could  be  hastened  if  the  deployment  of  the  OMG  Object  Request  Broker  and 
dependent  services  is  accelerated.  Currently  a  number  of  manufacturers  have  ORB  product 
available.  The  new  version  of  the  ORB  that  emphasizes  interoperability  is  not  yet  available.  One 
might  expect  its  specification  in  1994  with  implementations  in  early  1995.  The  ORB  and  its 
associated  suite  of  object  services  should  be  available  in  late  1995  or  early  1996.  These  services, 
which  cc  tld  be  based  on  DCE,  could  stimulate  the  development  of  distributed  services  and 
applications.  If  kept  on  track,  DCE,  DME,  and  the  ORB  should  enable  the  high  volume 
production  of  applications  by  1997. 
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1 4 .  INTERNATIONALIZATION 

14.1  ISO  Activities 

ISO/IEC  JTC1  SC22  established  WG20  to  examine 
issues  pertaining  to  internationalization.  Specifically,  the  role  of 
WG20  is  to  "identify  elements  relevant  to  the  work  of  SC22  that 
may  be  affected  by  differences  in  language,  culture,  customs  and 
habits;  for  these  elements,  [to]  develop  standards  that  enable 
applications  to  be  portable  across  differing  cultural  practices; 

[and  to]  develop  a  Technical  Report  that  describes  a  framework 
for  nations  to  provide  those  elements."  [SC22  N1424] 

To  this  end,  WG20  has  divided  its  work  into  three  parts: 

•  Preparation  of  a  Technical  Report  that  addresses  the  problems  that  need  to  be 
addressed,  and  the  tools  and  capabilities  that  programming  languages  need  to  provide, 
or  support,  in  order  to  enable  software  to  be  internationalized.  This  report  is  intended 
to  provide  enough  information  to  allow  SC22  WGs  to  establish  plans  for  the 
incorporation  of  internationalization  facilities  into  their  languages.  It  is  expected  to 
reach  PDTR  registration  and  ballot  in  mid  1994. 

•  Revision  to  TR  10176,  Guidelines  for  the  Preparation  of  Programming  Language 
Standards.  This  revision  will  consist  of  additional  new  sections  to  the  existing  TR  to 
address  the  particular  problems  of  internationalization.  It  is  expected  to  reach  PDTR 
registration  and  ballot  at  end  of  1994  or  early  1995. 

•  Preparation  of  several  international  standards  and  registries,  which  will  define  tools 
and  information  sources  that  can  be  used  by  programming  languages  to  provide 
specific  internationalization  functionalities. 

Two  existing  standards  that  provide  such  tools  are: 

•  ISO  10646-1,  Universal  Multi-Octet  Coded  Character  Set 

•  ISO  8859-1, 8-bit  Single-Byte  Coded  Graphic  Character  Sets,  Part  1:  Latin  Alphabet 
No.  1. 

One  standard  currently  being  worked  on  is  the  international  ordering  standard  for  data 
stored  in  ISO  10646-1  facilities.  This  standard  will  provide  a  default  international  ordering 
mechanism.  It  will  be  built  on  a  rich  character  set  that  allows  adaptation  to  a  specific  code  set  by 
subsetting  the  reference  repertoire  through  elimination  of  entries.  Additional  work  is  expected  in 
the  areas  of: 

•  A  specification  standard  for  cultural  conventions 

•  An  API  standard  for  internationalization 

•  A  registration  standard  for  cultural  convention  sets 

•  A  standard  for  a  modifiable  ordering  of  IS  10646  repertoire  strings 

•  A  standard  for  the  classification  of  IS  10646  repertoire  characters. 

ISO/IEC  JTC1/SC21  is  also  investigating  internationalization  of  directory  services 
[SC21  N  7019].  A  report  has  been  distributed  that  discusses  requirements  for  operating 
Directory  services  in  multi-national,  multi-lingual,  and  multi-cultural  environments  [SC21 N7931]. 
This  report  recommends  that  the  Directory  standard  be  enhanced  to  allow  attributes  and  Directory 
operations  to  contain  the  concept  of  locale'  and  proposes  a  model  for  this  enhancement  (Locale 
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refers  to  information  that  identifies  end-user  environment  elements  such  as  language,  character  set, 
and  cultural  preferences  for  items  such  as  date  and  time  display,  punctuation,  units,  and  so  on.) 
Specific  changes  required  in  the  Directory  standard  have  not  yet  been  identified. 

14.2  Assessment 

The  character  set  work  is  the  most  mature.  Some  industry  actions  have  also  occurred. 
MKS  has  announced  fully  internationalized  and  multibyte-enabled  versions  of  its  InterOpen  source 
code  products.  These  are  IntcrOpcn/Multihytc  POS1X  shell  and  utilities,  InterOpen/Multibyte 
SPG4  commands  and  utilities,  and  InterOpen/Multibyte  XPG4  terminal  interface.  Single  byte 
internalization  allows  text  messages,  input,  output,  and  data  processing  to  occur  in  most  languages 
for  which  a  single  byte  character  set  exists  •  such  as  French,  English,  and  German.  Multibyte 
internationalization  extends  this  to  accommodate  large  repertoire  languages  such  as  Japanese  and 
Chinese,  while  maintaining  support  for  single-byte  languages.  IBM  is  the  first  company  to  license 
the  internationalized  version  of  InterOpen/POSIX  shell  and  utilities,  and  implements  this  source 
code  on  its  mainframe  operating  system  OpenEdition  MVS. 
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15.  APPLICATIONS  AND  APPLICATIONS  PORTABILITY  INTERFACES 


15.1  Applications  Portability 

15.1.1  Requirements  for  Portability 

Portability  is  a  software  attribute  representing  the  ease 
and  cost  effectiveness  with  which  that  software  and  data  can  be 
used  on  heterogeneous  hardware/software  platforms.  Three  key 
determiners  of  portability  are  the  operating  system,  database 
access,  and  applications  software.  Hardware  environment 
changes  that  require  change  of  the  operating  system  are  in  many 
cases  significant  to  portability.  This  aspect  of  application 
portability  is  addressed  by  enforcing  a  standard  (POSDC)  for  an 
interface  between  the  operating  system  and  the  application 
program. 

The  interoperability  aspects  of  information  exchange 
mean  that  information  systems  need  to  have  a  consistent  way  to 
record  meanings  and  relationships  of  data,  and  to  distribute  and 
replicate  the  data  and  changes  to  the  data.  This  leads  to  the  need 
to  standardize  the  data  models  (schema)  for  databases  and  the 
services  for  accessing  those  databases.  SQL  is  an  example  of  a 
standard  for  services  supplied  to  applications  that  access 
databases  conforming  to  a  relational  data  model.  Additional 
standards  may  need  to  be  developed  for  other  data  models. 
Standards  for  development  of  applications  software  take  the 
form  of  programming  language  standards,  together  with 
standard  methods  for  using  the  programming  language. 
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Following  die  guidelines  and  standards  will  improve  die  prospects  of,  but  not  guarantee, 
application  portability.  Many  aspects  of  implementations  of  POSIX,  SQL,  and  Ada  environments 
are  inherently  hardware  dependent  Further,  the  standards  do  not  provide  all  the  needed  services. 
Use  of  nonstandard  options  available  in  the  implementations  of  operating  systems,  SQL,  and 
programming  languages  can  greatly  restrict  portability. 


15.1.2  Organizations  Promoting  Applications  Portability 


15.1.2.1  ISO 

In  April  1988,  JTC1  of  the  ISQflEC  began  a  formal  Joint  Technical  Study  Group  (TSG-1) 
for  Applications  Portability  (JTAP).  Managed  directly  under  die  JTC1,  and  not  any  of  the 
subcommittees,  the  JTAP  study  addressed  five  areas:  (1)  concepts  and  definitions  related  to 
applications  portability,  (2)  user  requirements,  (3)  portability  issues,  (4)  internationalization  (to 
investigate  the  interface  requirements  of  users  with  different  cultural  backgrounds)  (see 
Chapter  14),  and  (5)  a  framework  for  interfaces  for  applications  portability  (LAP).  The  final  report 
(Ref.  JTAP  1991]  contains  1 1  recommendations.  It  does  not  contain  an  explicit  list  of  application 
portability  standards  as  mentioned  in  the  original  mandate  because  such  a  list  would  comprise 
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almost  all  of  the  JTC 1  projects  and  standards.  The  recommendations  of  the  JTAP  report  are  that 
JTC1  should  do  the  following: 

1 .  Instruct  its  standards  groups  to  use  the  methods  and  concepts  described  in  the  report 

2 .  Establish  channels  of  communication  with  groups  outside  JTC  1  in  order  to  assist  them 
in  developing,  recording,  and  using  application  environment  profiles. 

3 .  Use  application  environment  profiles  to  identify  standards  work  needed. 

4.  Establish  procedures  for  managing  application  environment  profiles,  taking  both  user 
requirements  and  TR  10000-1 74  into  account 

5.  Establish  procedures  for  the  coordination  of  the  work  on  base  standards  and 
application  environment  profiles  that  may  lead  to  the  development  of  new  standards. 

6 .  Initiate  work  to  develop  a  taxonomy  for  application  portability. 

7.  Instruct  all  of  its  standards  groups  to  implement  the  portability  considerations  of 
Annex  A  [to  the  JTAP  report]  ("Necessary  Portability  Considerations  for  all  JTCl 
Standards  Development"). 

8 .  Publicize  activities  in  relation  to  the  development  of  standards  relevant  to  application 
portability  in  order  to  increase  user  awareness  and  participation,  and  promote  the  early 
use  of  standards. 

9.  Solicit  user  needs  and  priorities  when  initiating  and  guiding  work  relevant  to 
application  portability. 

10.  Review  its  mechanisms  for  coping  with  subjects  that  span  multiple  subcommittees 
such  as  application  portability,  security,  and  internationalization  (see  Chapter  14). 

11.  Establish  means  (e.g..  Special  Group)  for 

Interacting  with  user  groups 

Recording  application  environment  profiles 

Developing  a  taxonomy  for  application  portability. 

JTAP  terminated  on  September  1991.  As  a  result  of  the  JTAP  work,  SC22  has  initiated 
Working  Group  20  on  Internationalization  (see  Chapter  14).  The  Group  will  take  the  POSDC 
work  as  input  to  address  the  complex  technical  problem  of  porting  applications  across  other 
languages  and  cultures.  Likewise,  ASC  X3  has  formed  a  new  Technical  Committee,  X3T7  on 
Internationalization.  The  Japanese  National  Body  has  proposed  the  establishment  of  a  new  JTCl 
subcommittee  to  be  devoted  entirely  to  application  portability. 

ISO  has  recognized  that  standardization  is  needed  for  information  processing  that  goes 
beyond  data  communications  services  and  protocols.  As  will  be  shown  in  the  sections  that  follow, 
there  are  major  efforts  under  way  in  the  areas  of  standard  interfaces  to  operating  systems, 
databases,  graphics,  user  input  and  display  devices,  and  programming  languages.  In  addition, 
open  systems  standards  are  being  developed  for  document  interchange  and  distributed  processing. 

SC21  has  identified  (Ref.  SC21  N  3134  1988]  the  need  to  provide  standardization  in  the 
following  areas  related  to  information  system  interoperability: 

•  Information  exchange 

•  Internetworking  of  systems 

•  Specification  of  functions  needed  in  systems  built  for  specific  purposes 

•  Portability  of  applications  across  system  hardware  and  software 


74  TR  10000  is  in  ISO  technical  report  by  the  Special  Group  on  Functional  Standardization  (SGFS)  detailing  the 
framework  and  taxonomy  for  Internationa)  Standardized  Profiles  (ISPs).  See  Section  16.1.2. 
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•  Definition  of  common  interfaces  to  system  services 

•  Security  of  systems 

•  Reliability  of  systems 

•  Human-computer  (man-machine)  interfaces 

•  Definition  of  common  concepts 

•  Safety  and  legal  requirements. 

SC21  specifically  plans  to  address  standardization  for  database  management  systems  and 
single  and  distributed  processing  environments,  in  addition  to  open  systems  interconnection. 

15.1.2.2  National  Institute  of  Standards  and  Technology  (NIST) 

NIST  has  been  working  with  the  IEEE  and  other  US  organizations  to  identify 
environments  for  open  systems  that  can  be  specified  wife  existing  OSI  and  other  open  system 
standards.  The  NIST  recommendations  are  contained  in  the  APP,  which  is  discussed  in 
Section  15.1.3.3. 

15.1.2.3  X/Open 

X/Open  (see  Section  2.3  and  Appendix  F)  is  a  noh-profit  consortium  developing  a 
Common  Applications  Environment  (CAE)  to  promote  applications  software  portability.  X/Open 
relies  on  the  selection  and  adoption  of  de  jure  standards,  implementing  a  policy  of  using  these  in 
preference  to  development  of  its  own.  It  also  works  wife  other  specialist  consortia  to  develop 
specifications  that  help  to  accelerate  the  processes  of  standards  development  The  X/Open 
Portability  Guide  (XPG),  now  in  Version  4  (XFG4)  specifies  fee  CAE.  XPG4  represents  a 
significant  advance  over  previous  editions  in  that  about  half  of  fee  XPG4  components  relate 
directly  to  formal  standards.  Standards  recommended  for  the  CAE  are  discussed  in 
Section  15.1.3.4. 

X/Open  has  entered  into  an  agreement  to  acquire  the  UNIX  trademark  from  Novell  (who 
purchased  UNIX  International  in  1992).  When  finalized,  fee  UNIX  name  will  be  used  to  brand 
systems  feat  comply  wife  the  UNIX  API  (also  called  the  Common  OS  API  or  1170  API) 
developed  by  X/Open  (see  also  Section  10.23).  The  UNIX  API  combines  functions  of  SVR4, 
IBM’s  ADC.  Hewlett  Packard’s  HP-UX,  and  OSFs  OSF/1.  [Ref.  OSN  1993q]  Since  no  system 
currently  complies  wife  the  whole  1170  specification,  an  interim  agreement  has  been  set  up 
whereby  suppliers  can  use  the  UNIX  brand  immediately  if  all  of  the  following  conditions  are 
satisfied  [OSN  1993r]: 

•  The  system  conforms  to  X/Open's  XPG3  or  4  base,  and  fee  USL  System  V  Interface 
Definition  (SVID  2  or  3). 

•  The  system  is  derived  from  USL  operating  system  technology. 

•  The  supplier  has  committed  to  delivering  the  1 170  APL 

15.1.2.4  Open  Software  Foundation  (OSF) 

The  Open  Software  Foundation  (OSF)  (see  also  Appendix  F)  is  an  international  consortium 
of  over  360  members  including  commercial,  government,  and  university  groups  formed  in  May 
1988  to  promote  applications  portability.  It  is  a  technology  integrator  and  distributor  of  Open 
Systems  Technology  wife  over  300  employees  worldwide.  Its  technology  products  include  an 
operating  system,  OSF/1  Release  1.2  (see  Section  10.2.2);  a  visual  user  interface  and  toolkit. 
Motif  1.2  (see  Section  5.2.7);  and  a  distributed  computing  environment,  DCE  1.0.2A  (see 
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Section  13.4.1).  Products  in  progress  include  components  of  a  distributed  management 
environment  (DME)  (see  Section  13.4.2).  Research  at  the  OSF  Research  Institute  is  leading  to  an 
architecture  neutral  distribution  format  (ANDF)  methodology  (see  Section  15. 1.3.5)  for 
distributing  portable  software  and  a  microkernel  (Mach)  (see  Section  10.2.2)  on  which  later 
versions  of  UNIX  can  be  based.  Other  standards  recommended  for  OSF  are  identified  in 
Section  15.1.3.5. 

The  role  of  OSF  is  to  determine  the  user's  requirements  for  a  function;  to  request 
information  on  the  availability  of  current  products  to  satisfy  that  function;  to  select  appropriate 
technology  from  vendors,  securing  the  ability  to  license  its  offering  to  all  at  reasonable  terms;  to 
integrate  the  technology  into  a  reference  offering;  and  to  distribute  source  code  for  the  reference 
product  to  all  licensees. 


15.1.2.5  OIW  Technical  Committee  on  OSE  (OSE-TC) 


In  1991,  the  OIW  changed  its  name  from  the  OSI  Implementor’s  Workshop  to  the  OSE 
Implementor’s  Workshop.  At  the  same  time,  it  established  a  Technical  Committee  on  OSE 
(OSE-TC).  In  December  1993,  the  OSE-TC  formed  five  subcommittees  to  focus  on  specific 
issues  being  addressed  by  the  OSE-TC.  The  committees  are  the  following  [Ref.  Johnson  1994]: 

•  Profiling  Work/Issues  Stihrnmmmre — PmvicW  guidance  on  the  development  of  user 

defined  Open  Systems  Environment  (OSE)  profiles.  Guidance  will  build  on  work 
done  by  the  ISO/IEC  JTC1/SGFS  in  ISO/IEC  TR  10000-3,  Principles  and  Taxonomy 
for  OSE  Profiles  (OSE-TC/93-084)  and  the  EWOS)  document.  Method  for 
Developing  and  Documenting  OSE  Profiles  (OSE-TC/93-064).  Specifically  the 
subcommittee  will: 


Define  and  prototype  a  user  profile  development  methodology 
•  Document  and  analyze  the  user  profile  development  methodologies  of  the  OIW 
SIGs  such  as  the  Desktop  Environment  SIG,  Multimedia  SIG,  and  Healthcare 
SIG. 

Coordinate  with  ISO,  OIW  SIGs,  other  Regional  Workshops  (EWOS  and  AOW) 
and  user  organizations  who  have  expressed  an  interest  in  developing  OSE 
profiles. 

Work  items  will  include  the  following:  guide  to  profile  writers  on  how  to  develop  and 
document  OSE  profiles;  prototype  OSE  profile(s);  and  input  to  ISO,  OIW  SIGs  and 
other  regional  workshops  on  developing  OSE  profiles. 

OSI  and  TCP/IP  Convergence  Subcommittee — developed  a  strawman  outline  of 
convergence  profiles  that  identified  areas  that  require  profiling  and  the  profiles  needed 
in  each  area;  addressing  federal/user  group  procurement  mandates,  Internet  IP  next 
generation  (IP:ng),  user/vendor  profiles,  catalog  convergence  and  coexistence  (CC) 
technology,  and  consensus  CC  strategies/architectures. 

JBkflmmfi  Commerce  Subcommittee — addresses  proliferation  of  EDI  conventions  or 
implementation  agreements  covering  the  procurement  related  transaction  sets  and  the 
technical  issues  involved  in  integration  of  EDI/EDIFACT  with  information 
technologies,  to  include  the  following: 

Communications  (OSI  and  Internet) 

Security,  privacy,  non-repudiation 
Electronic  mail  (OSI  and  Internet) 

Multimedia 

Database 

Application  programming  interfaces 
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Testing  to  be  done  for  compliance  with  EDI  standards 
EDI  input  and  output  option  for  applications  software 
EDI  enveloping  implementation  agreements  for  Internet  and  OSI  protocols. 

•  Desk  Top  Sub-Committee — The  Desktop  Environment  SIG  addresses  issues  affecting 
the  end  users’  interaction  with  their  computing  environment,  a  scope  independent  and 
complementary  to  the  other  OIW  SIGs.  Specifically,  the  SIG  employs  standards  and 
publicly  available  specifications  for  protocols  and  interfaces  to  develop  profiles  to 
access  functionality  available  from  the  desktop.  Issues  falling  under  this  charter 
include  standard  desktop  tools,  graphical  user  interfaces,  multimedia  interfaces,  object 
management,  the  coexistence  and  convergence  of  multiple  environments,  the  transition 
from  standalone  systems  to  distributed  environments,  and  the  need  for  publicly 
available  specifications  of  proprietary  interfaces.  The  SIG  determines  which  interfaces 
map  to  existing  profiles  and  identify  gaps  within  those  profiles.  Work  items  include 
the  following: 

Define  and  clarify  the  scope  of  the  desktop  environment  and  the  SIG  relationship 
to  the  other  service  areas  identified  by  various  profiling  methodologies. 

With  the  assistance  of  the  OSE  Technical  Committee,  assess  the  appropriateness 
of  these  methodologies  for  meeting  identified  user  requirements  for  the  desktop 
environments. 

Develop  a  profile  for  end  user  access  to  multiple  environments  from  a  single 
device  (personal  computer  or  workstation). 

Using  established  OIW  procedures,  identify  the  publicly  available  specifications 
and  their  reference  implementations  for  standalone  and  distributed  desktop 
environments. 

Develop  a  profile  for  achieving  user  portability  across  different  standalone 
desktop  environments. 

Identify  appropriate  transition  methodologies  for  migration  from  single-user  to 
distributed  environments,  independent  of  underlying  hardware  and  operating 
system  implementation. 

Develop  a  profile  for  user  portability  across  different  distributed  desktop 
environments,  including  those  environments  available  from  POSIX  compliant 
vendors. 

*  Distributed  Computing  Sub-Committee — Addressing  middleware  (application  support 
software)  and  other  topics  related  to  distributed  computing  standardization. 

TCP/IP-OSI  Convergence  and  Coexistence  (CC).  The  NIST  developed  two 
papers  addressing  the  convergence  issue  and  distributed  them  to  the  December  1993  meeting  of  the 
OSE-TC:  Protocol  Coexistence  and  Convergence  (OSE-TC/93-154),  and  Functional  Comparison 
of  the  Internet  Protocol  Suite  and  die  OSI  Protocol  Suite  (OSE-TC/93-155). 

Electronic  Commerce  (EC).  In  December  1993,  the  OSE-TC  hosted  a  special  session 
on  Electronic  Commerce  with  representatives  from  federal  and  state  government,  industry 
associations,  and  the  electronic  data  interchange  (EDI)  standards  organizations  (DISA  and 
ANSI  X12).  The  key  issue  is  the  US  Federal  Government’s  requirement  to  start  implementing 
Electronic  Commerce  by  September  1994  (OSE-TC/93-171).  In  October  1993,  President  Clinton 
signed  an  Executive  Memorandum  to  federal  agency  heads  regarding  electronic  contracting  (OSE- 
TC/93-132).  However,  the  Federal  EDI  community  has  become  concerned  over  the  proliferation 
of  EDI  conventions  or  implementation  agreements  covering  the  procurement  related  transaction 
sets.  This  meeting  provided  the  first  forum  for  bringing  together  government  users  and  industry 
associations  to  address  these  concerns  and  identify  areas  for  cooperation  and  develop  plans  for 
implementing  Electronic  Commerce.  Government  users  will  identify  requirements  and  provide  this 
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information  to  DISA/ANSI  X12  for  identification/development  of  transaction/message  set 
guidelines.  The  OSE-TC  will  develop  a  technical  assessment  of  OSI,  Internet  and  other  protocols 
required  to  support  Electronic  Commerce.  The  assessment  will  also  address  government  policy 
barriers  to  implementation.  The  EC  subcommittee  developed  an  action  plan,  scope  of  work,  and 
objectives  for  the  assessment  to  be  presented  at  the  next  meeting  (OSE-TC/93-195). 

Public  Windows  Interface  (PWI).  Users  and  vendors  have  invested  substantially  in 
Microsoft  Windows  Applications  and  need  an  agreed  standard  for  PWI.  Both  groups  are 
concerned  about  the  portability  of  applications  and  personnel  to  platforms  with  other  graphical  user 
interfaces.  A  draft  PWI  specification  was  developed  by  SUN,  IBM,  X/Open  and  others,  which  is 
not  made  up  of  any  Microsoft  code.  The  PWI  provides  a  common  application  programming 
interface  (API)  for  personal  and  productivity  applications.  PWI  aims  to  ensure  portability  of  these 
applications,  as  applications  written  in  compliance  with  this  API  will  run  on  any  PWI-compliant 
desktop.  The  PWI  specification  will  be  submitted  to  major  industry,  national  and  international 
standards  organizations  for  acceptance  as  a  public  standard. 

National  Standards  System  Network  (NSSN).  ANSI  has  obtained  federal  funding 
for  the  NSSN  from  the  Technology  Reinvestment  Project  (TRP).  A  team  led  by  ANSI  will 
develop  an  electronic  network  to  link  the  heterogeneous  databases  of  hundreds  of  organizations 
involved  in  the  development,  production,  distribution,  and  use  of  technical  standards  in  the  United 
States.  This  electronic  information  infrastructure  will  reduce  standards  development  time, 
minimize  duplication  of  effort,  and  decrease  production  costs. 

Protocol  Independent  Interfaces  for  Process-to-Process  Communications. 
NIST  is  working  on  convergence  APIs  for  Internet  and  OSI  network  process-to-process 
communications  through  the  POSIX  P1003.12  Committee.  P1003.12  Draft  4.0  specifies  a  low- 
level  Detailed  Network  Interface  (DNI)  that  provides  access  to  protocol-specific  features  of  the 
underlying  network.  DNI  consists  of  the  X/Open  Transport  Interface  (XU)  and  the  BSD  Socket 
Interface  (XTI  does  not  provide  access  to  the  identical  set  of  services  as  Sockets).  The  first  ballot 
for  1003.12  closed  in  October  1993.  Draft  4.0  includes  two  C  bindings  for  DNI  (XTI  and 
Sockets),  event  management  interface,  language-independent  interface  mappings  for  protocol 
profiles,  C  binding  interface  mappings  to  protocols,  and  relationship  between  bindings  and  LIS. 
The  focus  is  portability  of  applications  between  open  networks.  Applications  that  use  XTI  and 
Sockets  can  run  over  both  OSI  and  Internet  protocols. 

IS.  1.2.6  Desktop  Management  Task  Force  (DMTF) 

The  DMTF  is  a  supplier-led  group  that  will  develop  specific  de  facto  standards  for 
managing  elements  within  networked  desktop  systems.  It  was  founded  at  the  Spring  1992  Interop 
trade  show  by  Microsoft,  Novell,  IBM,  Digital  Equipment,  Hewlett-Packard,  SunConnect,  and 
Synoptics,  and  at  least  150  members  have  joined  since.  DMTFs  tasks  are  the  following: 

•  Define  a  set  of  open  APIs,  called  the  Desktop  Management  Interface  (DMI;  see  Section 
15.1.3.10)  for  managing  desktop  systems 

•  Define  a  simple  method  of  managing  desktop  components 

•  Distribute  the  specification  and  a  reference  implementation  at  no  charge  to  hardware 
and  software  vendors. 

DMTF  hopes  the  result  will  be  a  set  of  rules  for  accessing  multiple  hardware  and  software 

components  on  a  desktop  computer  consistently  across  multiple  management  platforms.  The 
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interfaces  between  components,  local  agent,  and  management  application  are  independent  of  any 
one  operating  system,  network  operating  system,  or  protocol.  [Ref.  OSN  1993] 

15.1.3  Standards  for  Applications  Portability 

This  section  discusses  the  standards  recommended  as  profiles  for  applications  portability. 
The  areas  addressed  are  interfaces  for  applications  portability,  NIST  APP,  UK  MOD  Model, 
X/Open  CAE,  OSF,  the  Technical  and  Office  Protocol  (TOP),  Multivendor  Integration  Architecture 
(MIA),  EWOS  profiles  for  open  system  environments,  UNIX  International's  ATLAS  (UI- 
ATLAS),  die  Desktop  Management  Interface  (DMI),  and  the  SPIRIT  (Service  Providers  Integrated 
Requirements  for  Information  Technology)  project  Several  of  the  profiles  discussed  here  and 
elsewhere  are  procurement  profiles.  The  first  procurement  profile  was  General  Motors'  MAP 
protocols  (see  Section  9.11.5.1) ,  and  perhaps  the  most  powerful  has  been  the  government  OSI 
profiles  (GOSIPs)  (see  Section  16.1.3).  Other  profiles  currently  active  include  the  NTTs  MIA 
(see  Section  15.1.3.7),  and  the  Telcos'  SPIRIT  (see  Section  15.1.3.11). 

15.1.3.1  Interfaces  for  Applications  Portability  (IAP) 

JTAP  [Ref.  JTAP  1991]  examined  the  interfaces  that  need  to  be  standardized  in  order  to 
facilitate  portability  of  applications.  It  concluded  that  there  are  three  types  of  portability: 
programs,  data,  and  people.  Thus,  standards  relevant  to  IAP  must  address  the  following: 

•  Source  code  portability 

•  Data  portability 

•  User  interface 

•  Documentation  portability 

•  Operating  system  interfaces 

•  Communication  services 

•  Database  management  services 

•  Software  engineering  tool  interfaces 

•  Internationalization. 

Further,  the  JTAP  study  identified  the  following  IAP  issues  to  be  addressed  in  JTC1: 

•  Standards  need  to  define  consistent  handling  for  exceptions  encountered  by 
applications  during  execution. 

•  Standards  need  to  identify  ways  to  enable  adaptation  of  applications  by  automated 
means  to  accommodate  options  and  other  environmental  variations  (e.g., 
implementation-defined  characteristics,  option  identification). 

•  Standards  for  IAP  need  to  take  into  account  external  object  names,  providing  methods 
to  minimize  the  impact  of  variations  of  external  object  names  across  application 
platforms.  Language  standards  need  to  provide  corresponding  services  and 
capabilities  to  enable  applications  to  accommodate  these  variations  (e.g.,  variable 
length  strings,  services  for  acquiring  object  names  from  external  sources,  object  name 
composition/decomposition). 

•  Qualitative  metrics  for  application  portability  may  be  useful. 

IAPs  can  be  language  independent,  operating  system  independent,  or  both.  Proposed 
work  in  SC21  will  be  for  IAPs  that  are  both  language  and  operating  system  independent 
Language-specific  constructs  could  be  developed  in  SC22,  as  the  mapping  of  abstract  data  types  to 
language-specific  constructs  is  primarily  the  work  of  defining  language  bindings. 
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Specification  of  an  IAP  would  include  definition  of  data  types  of  the  interfaces  and  may 
include  rules  for  describing  behavior  and  sequencing  of  functions  within  an  interface  (e.g., 
blocking  or  non-blocking  procedure  calls)  and  levels  of  enforcement  of  these  rules.  A  model  of 
IAPs  is  needed  and  should  be  related  to  or  possibly  included  in  the  models  for  Extended  A1X 
(Application  Layer  Structure)  (XALS)  and  ODP.  It  was  proposed  that  the  IAP  model,  as  well  as 
the  XALS  and  ODP  models,  should  include  a  means  to  extend  the  interface  to  include  user-  or 
application-specific  extensions  or  abstractions.  For  example,  it  should  be  possible  to  invoke  a 
procedure  to  store  application  data  type  within  the  X.500  Directory  Service  without  changing  the 
interface  definition.  [Ref.  SC21  N  4523  1990] 

15.1.3.2  Open  Systems  Environments  (OSE) 

The  IEEE  and  NIST  are  promoting  the  concept  of  an  Open  System  Environment  (OSE), 
which  IEEE  P  1003.0  defines  as: 

The  comprehensive  set  of  interfaces,  services,  and  supporting  formats,  plus  user 
aspects,  for  interoperability  or  for  portability  of  applications,  data,  or  people  as 
specified  by  information  technology  standards  and  profiles. 

An  OSE  is  the  basis  for  profiles.  The  NIST  APP  OSE/1  and  POSIX  are  both  examples  of 
OSEs.  By  contrast,  a  profile,  as  defined  by  IEEE  P1003.0  is: 

A  set  of  one  or  more  base  standards,  and  where  applicable,  the  identification  of 
chosen  classes,  subsets,  options,  and  parameters  of  those  base  standards, 
necessary  for  accomplishing  a  particular  function. 

A  profile  is  a  list  of  standards  as  opposed  to  an  OSE,  which  is  a  list  of  services.  Profiles 
are  therefore,  subsets  of  OSEs.  They  do  not  specify  functionality,  but  combine  multiple  base 
standards,  choose  and  select  options  and  parameters,  and  address  coherence  among  the  base 
standards.  [Ref.  Gambrel  1991]  Likewise,  EWOS  has  expanded  the  scope  of  SGFS  to  include 
OSE  (see  Section  15.1.3.8). 

Figure  15  provides  an  example  of  a  model  for  an  open  systems  environment  developed  by 
the  UK  MOD  [Ref.  MOD  1989]  and  used  to  promote  applications  portability.  It  includes  users, 
developers,  managers,  and  providers.  It  also  explicitly  includes  security  and  OSI  system  and 
project  management 

15.1.3.3  NIST  Applications  Portability  Profile 

This  section  discusses  the  APP  developed  by  the  NIST.  The  NIST  approach  to 
applications  portability  is  based  on  an  architectural  approach  that  provides  interfaces  for 
functionality  to  accommodate  a  broad  range  of  applications  requirements.  The  functional 
components  of  the  architecture  are  viewed  as  a  "tool  box"  of  standard  elements  that  can  be  used  to 
develop  and  maintain  portable  applications.  These  tools  are  based  on  an  open  systems  concept  and 
are  required  to  be  developed  as  an  integrated  collection  of  non-proprietary  standards.  The  NIST 
OSE  embraces  three  concepts: 

•  Extensibility — Based  on  an  architectural  framework  that  allows  an  extensible  collection 
of  interfaces,  services,  protocols,  and  supporting  formats  to  be  defined 

•  Non-proprietarv — Interfaces,  services,  protocols,  and  supporting  formats  defined  in 
non-proprietary  specifications 

•  Consensus  based — Evolution  is  controlled  by  a  consensus- based  process  for 
definition  and  specification  of  interfaces,  services,  protocols,  and  supporting  formats. 
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Figure  15.  A  MoM  for  tho  Opon  Systems  Environ  mint 


Moreover,  it  stresses  the  following: 

•  Portability— The  ability  to  use  application  software  and  data  on  heterogeneous 
hardware  and  software  platforms 

•  Interoperability — The  ability  to  have  application  and  software  operating  on 
heterogeneous  hardware  and  software  platforms  cooperate  in  perforating  some  user 
function 

•  Scalability — The  ability  to  use  the  same  applications  software  on  many  different 
classes  of  hardware  and  software  platforms,  from  personal  computers  to 
supercomputers. 

A  full  complement  of  standards  should  be  available  under  the  APP  by  1995.  [Ref. 
APP 1991]  Version  2  of  the  Application  Portability  Profile  (APP):  The  U.  S.  Government's 
Open  System  Environment  Profile  OSE/1,  NIST  SP  500-210  was  published  in  June  1993.  It 
recommends  standards  and  specifications,  provides  guidance  in  areas  where  standards  do  not  exist 
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for  seven  service  areas,  and  makes  strategic  evaluations  with  respect  to  those  standards.  The  three 
strategic  classifications  arc: 

•  Strategic  now — Users  reasonably  safe  in  making  substantial  investment  and  long-term 
plans  in  mission-critical  systems  and  infrastructure 

•  Strategic  in  the  future — Specifications  subject  to  change  but  appear  to  be  headed  for 
standardization;  some  risks  but  consensus  process  minimizes  them 

•  Nonstrategic — Stop-gap  recommendations  with  warning  that  user  investment  will  be  at 
significant  risk;  not  appropriate  for  long-term  planning. 

APP  specifications  are  selected  according  to  the  following  order  of  precedence: 
International  Standards,  US  National  Standards  (e.g.,  ANSI,  IEEE),  US  National  Standards 
Committee  work  in  progress,  other  Federal  standards  (e.g.,  DoD  standards),  and  specifications 
that  are  publicly  available  and  for  which  implementations  are  commercially  available  from  a  variety 
of  sources  (e.g.,  X- Window  System,  Version  1 1).  (Ref.  Fisher  1991] 

Figure  16  provides  a  high-level  view  of  the  architectural  approach  that  underlies  the  APP. 

OSE  SERVICES 


Source:  [Ref.  APP  1992];  updated  from  [Ref.  APP  1993], 

Figure  16.  An  Example  View  of  the  Architecture  for  the 
Applications  Portability  Profile 


Table  38  identifies  the  elements  (tools)  and  the  associated  interface  specifications  of  the 
recommended  standards  (Ref.  APP  1993]  for  the  APP.  The  key  elements  are  OSI  for  data 
communications;  (extended)  POSIX  for  the  operating  system  interface;  SQL  and  IRDS  for 
database  management;  and  X-Windows  for  the  human/computer  interface. 

An  extended  version  of  POSIX  is  recommended  in  the  APP  for  the  operating  system 
interface  (sec  Section  10.2.1).  NIST  has  a  FIPS  on  the  Government  Network  Management  Profile 
(GNMP)  for  network  management  (FIPS  179)  (see  Section  10.2.1.1  and  12.1).  SQL  (see 
Section  6.2.2.2)  and  the  Information  Resource  Dictionary  System  (IRDS)  data  dictionary  standard 
[Ref.  Goldfine  1988]  (see  Section  6.2.4)  are  recommended  for  database  management  The 
distributed  data  component  will  be  handled  through  Remote  Database  Access  (RDA)  (see  Section 
6.2.3).  Recommended  for  data  interchange  are  the  following: 

•  Computer  Graphics  Metafile  (CGM)  (see  Section  7.2.2.2) 

•  Initial  Graphics  Exchange  Specification  (IGES),  used  for  engineering  graphics  (see 
Section  7. 2. 1.1) 

•  Standard  for  the  Exchange  or  Product  Model  Date  (STEP)  (identified  in 
Section  7.2. 1.2) 
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•  Electronic  Manuscript  Preparation  and  Markup  (EMPM)  (see  Section  7.1.2) 

•  Standard  Generali  red  Markup  Language  (SGML)  (see  Section  7.1.2) 

•  Office  Document  Architecture/Office  Document  Interchange  Format  (ODA/ODIF)  (aee 
Section  7.1.1) 

•  Spatial  Data  Transfer  Specification  (SDTS)  (see  Section  7.3.8). 

Table  38.  Standards  for  the  Applications  Portability  Profile 


Function 

Element 

Rafarenca  for  Standerda 

Operating  System 

POSIX 

IEEE  Std.  1003.1-1990  (FIPS  151-2) 

POSIX  SHELL 

IEEE  Std.  1003.2,  Saplambar  1992 

REALTIME 

IEEE  P1003.4 

IEEE  P1003.6 

Data  Management 

SQL2 

ISO  9075:1992  (RPS 127-2) 

IRDS 

ANSI  X3. 138-1 968  (RPS  158) 

FDA 

ISO  9759:1992 

Data  Interchange 

Document  interchange 

SGML 

ISO  8879.  ISO  9069.  ISO  9070,  TR  9573 
(RPS  152)  1 

ISO  8813 

OQAODIF 

SPDL 

DiS  10180  (planned  RPS) 

CLiDLi 

ANSI  Z36.50  - 1968 

EDI 

RPS  161 

Graphic  Data  Interchange 

COM 

ISO  8632  (RPS  128) 

K3ES 

N8SJR  88-3813,  ANSI  Y  14.26  (RPS  17 7) 

-  Product  Ufa  Cycle  Data 

STEP 

CD  10303 

Interchange 

•  Spatial  Data  Interchange 

SOTS 

RPS  173 

Graphice  Services 

ISO  7942,  ISO  8851,  ISO  8805  (RPS  120-1) 

PHM3S 

ISO  9602  (FIPS-153) 

Nitwofk  Sanricaa 

GOSIP  II 

RPS  148-1 

API 

IEEE  Pi 003. 12.  Draft  2 

ACSE 

IEEE  PI  238 

FTAM 

IEEE  P1238.1 

GOSIP  III 

(planned  RPS  148-2) 

ISDN  API 

Version  1  from  ISON  Users  Forum 

ISON 

ISDN-RPS 

OSFDCERPC 

Draft 

TFA 

IEEE  PI  003.8,  (planned  RPS) 

GNMP 

FIPS  179 

X.400  API 

IEEE  P1224.1 

X.500  API 

IEEE  P1224.2 

Human  Computer  Interface 

V  an* — i - 

A'rrfKXnel 

R  PS-1 58-1 

Modular  Toolkit 
Environment 

IEEE  P1296.1 

Softvwi  Engineering  Senricee 

c 

ANSI  X3J1 1/88-1 61 -Oct  1988.X3.159 

COBOL 

ANSI  X3£3*1974, 85  (FIPS  021-3) 

ANSI  X3.9-1978  (RPS  089-1) 

Ada 

FIPS  119 

Paacal 

ISO  7185-1963  (RPS  109) 

PCTE 

ECMA 

8eurca:  Application  PortabUty  Protib  The  US  Oovommcntc  Open  System  Environmont  Profs  OSE/1, 
Version  2,  NIST  Special  PuMcation  500-210,  NIST,  Juno  1093. 


Graphics  Kernel  System  (GKS)  and  Programmer's  Hierarchical  Interactive  Graphics 
System  (PHK5S)  are  recommended  for  Graphics  Services  (see  Sections  8.2  and  8.3). 
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Standards  and  options  identified  in  US  GOSIP  Version  2  (see  Section  16.1.3)  are 
recommended  for  network  services,  as  well  as  ISDN  and  Transparent  File  Access  (TFA).  OSF 
Distributed  Computing  Environment  (DCE)  RPC  component  is  recommended  for  distributed 
computing  services  until  RPC  becomes  an  international  standard.  X-Windows  is  recommended 
for  the  human  computer  interface,  providing  a  non-proprietary  windowing  capability. 

Five  standard  programming  languages  are  recommended  (C,  COBOL,  FORTRAN,  Ada, 
and  Pascal),  but  standard  bindings  to  POSIX  for  some  of  these  languages  (all  but  C)  are  still  being 
defined.  (Ref.  Martin  1990;  Hankinson  1988;  APP  1990]  In  addition,  the  ECMA's  Portable 
Computer  Tools  Environment  (PCTE)  (see  Section  4.3.2.2)  is  being  recommended  for  the 
programming  service  environment. 

Future  updates  will  be  expanded  to  address  distributed  computing  requirements  such  as 
uniformity,  transparency,  federation,  and  optimization  and  to  include  system  security  and  system 
management  services.  Moreover,  future  updates  will  include  a  user  requirements  framework  that 
will  lend  a  more  user-oriented  approach  to  application  and  organizational  profile  development  It 
will  consist  of  a  framework  and  taxonomy  for  describing  user-specified  system  functionality, 
examining  EWOS  and  UK  work-in-progress  as  a  basis  for  the  user  requirements  framework. 

In  November  1993,  NIST  issued  a  Draft  Guide  on  Open  System  Environment  (OSE) 
Procurements,  which  is  expected  to  be  published  in  1994.  The  report  provides  agency  program 
managers,  system  engineers,  and  contracting  officers  with  a  model  for  developing  the  plans  and 
specifications  necessary  to  define  the  OSE  requirements  in  requests  for  proposals.  Additional 
information  is  provided  for  assisting  agencies  in  determining  which  portions  of  the  report  are 
applicable  to  their  specific  acquisition  plans.  Lessons  learned  are  highlighted  in  annotated  text  that 
accompanies  many  of  the  report's  subsections.  (Ref.  OSE  1993] 

The  IEEE  Computer  Society's  Portable  Application  Standards  Committee  (PASC) 
[formerly  Technical  Committee  on  Operating  Systems  (TCOS)]  has  formed  a  number  of  working 
groups  to  progress  POSIX  and  other  standards  that  are  required  to  facilitate  applications 
portability.  Table  39  identifies  the  documents  (and  working  groups  known  by  the  same  name) 
being  prepared  by  IEEE  on  areas  other  than  POSIX  for  application  portability.  [Ref.  NIST  1990a] 
The  scope  and  status  of  POSIX  standards  work  are  discussed  in  Section  10.2.1. 

A  review  of  the  interface  specifications  for  the  APP  shows  that  there  are  not  yet 
international  standards  for  many  of  the  elements  of  the  recommended  architecture.  Some  are  being 
considered  by  ANSI,  IEEE,  and  other  standards  defining  bodies,  and  others  are  US  standards. 
For  example,  X-Windows  is  being  considered  by  the  ANSI  X3H3.6  working  group,  and  has  been 
promulgated  as  FIPS  158.  The  C  language  bindings  are  being  considered  by  the  X3J1 1  ANSI 
working  group.  NIST  is  developing  interim  standards  for  file  management  and  is  recommending 
Network  File  Server  (NFS)  to  IEEE  PI 003  as  the  best  starting  point  for  these  interfaces.  [Ref. 
Hankinson  1988]  The  engineering  graphics  standard  (IGES)  is  still  only  available  as  a  NIST 
publication. 

Table  40  gives  an  evaluation  of  the  stability  and  completeness  of  the  standards 
recommended  by  NIST  for  the  APP.  Each  standard  in  the  seven  service  areas  (security  is  not 
addressed)  is  identified  by  source  and  given  a  strategic  evaluation;  strategic  now  (STR),  strategic 
in  the  future  (FTR),  and  non-stratcgic  (GAP). 
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Tabl*  39.  Applications  Portability  Standards  Being  Developed  by  IEEE  tor  Submission 

to  ISO  Through  ANSI 

Pi 003.0,  A  Guide  to  POSIX  Baaed  Open  Syeteme  Architectures— addresses  the  broad  apptcations  portability 
issues,  such  as:  benefits  and  risks  of  open  system  architecture,  architectural  framework  for  portability, 
applications  portability  concepts,  operating  systems  services,  data  management  and  interchange  services, 
data  interchange  services,  graphics  services,  network  services,  user  interface  services,  and 
languagea/application  development  environment  services _ 

P1201.1,  Untom  Application  Program  Interlace — defines  an  API  for  GUI  visual  objects  and  windowing  services 
that  is  imp  lamentable  on  multiple  window  systems  and  GUI  toolkit  APIs.  Base  document  is  XVT.  Ballot 
expected  2Q  1993. _ 

Pi  201 .2,  Driveability— defines  a  recommended  practice  for  those  elements  and  characteristics  of  user  interfaces 
that  must  be  consistent  to  permit  users  to  easily  transfer  from  one  look-and-feel  or  application  to  another  (Balot 
June  1992;  standard  expected  mid-1993) 

Pi  201 .3,  User  Interface  Management  System  (UIMS)— defines  a  language-independent  dialogue  applications 
programming  interface  to  develop  applications  systems  that  are  independent  of  user  interface  concerns  and 
can  be  more  easily  ported  across  a  wide  range  of  user  interface  styles  and  technologies:  would  address  such 
features  as:  separation  of  presentation-dependent  and  presentation-independent  aspects,  and  mechanisms 
for  data  and  control  exchange  between  application  and  dialogue  layers  (not  yet  approved  by  TOPS) 

1224,  OSI  Abstract  Data  Manipulation  API  (US)— defines  a  standard  interface  supporting  the  manipulation  of 
complex  arguments  and  parameters  used  by  X.400  and  Directory  Services  APIs,  Published  1993. _ 

1224.1,  X.400  Based  Electronic  Messaging  API  (US)— defines  an  X400  API  that  makes  the  functionality  of  a 

message  transfer  system  (MTS)  accessible  to  a  message  store  (MS)  or  user  agent  (UA)... defines  an  X.400 
Gateway  API  with  two  components:  a  mail  system  gateway,  and  an  X.400  gateway  sendee.  Base  document  ia 
from  X.400  API  Association  and  X/Open.  Work  to  be  done  before  the  ballot  include,  adding  language 
independence  features,  adding  assertions  and  other  test  methods,  and  reformatting  the  standard  into 
IEEE/ISO  form.  Published  1993. _ 

1224.2,  Directory  Services  Application  Programming  Interface  (API)  -  Language  Independent  Specification— 
defines  a  language  independent  API  to  a  directory  service  including,  but  not  neeessarly  limited  to.  ITU-TS 
X.800  functionality 

PI 237,  Remote  Call  Procedure  (RPC)  Interface  Language— define*  an  interface  description  language  and  a  very 
limited  set  of  procedure  interfaces  to  alow  applications  to  use  an  underlying  RPC  mechanism  layered  on  an  OSI 
stack  (balot ing  planned  for  mid-1992  and  approval  early  In  1993) _ 

PI  238  OSI  Application  Program  Interfacee  defines  an  API  model  for  connection-oriented  OSI  Application  Layer 
services.  Draft  14,  August  1982.  In  balot 

Pi 238.1,  FTAM  OSI  Application  Program  Interfacee— provides  an  application  program  interface  to  the  detaled 
OSI  FT AM  services  and  higher-level  user-oriented  FTAM-based  sendees  (balot  In  1993) _ 

PI 295.1,  X  Window  System  Graphical  User  Interface,  Part  1:  Modular  Toolkit  Environment  -  defines  a  source 
code  level  interface  to  an  X  window  system  toolkit  GUI  environment  based  on  OSF  MOTIF  Application 
Environment  Specification _ _ _ 

PI  326,  Test  Methods  for  Measuring  Conformance  to  OSI  Abstract  Data  Manipulation  -  API— defines  the  test 
methods  to  be  used  to  measure  conformance  to  IEEE  Standard  1224 

Pi  326.1,  Teat  Methods  for  Measuring  Conformance  to  X.400  Baaed  Electronic  Meseaging  Application  Program 
Interfaces  (API)  [Language  Independent}— define*  the  test  methods  to  be  used  to  measure  conformance  to 
IEEE  Standard  1224.1 _ 

1326.2,  Test  Methods  for  Directory  Services  Application  Programming  Interface  (API)  •  Language  Independent 

Specification— defines  the  test  methods  to  be  used  to  measure  conformence  to  IEEE  Standard  1224,2 _ 

1327,  OSI  Abstract  Data  Manipulation  API,  Published  1993. _ 

1327.1,  X400  Based  Electronic  Meseaging  C  Language  Interfaces  -  BMng  hr  Applications  Program  Interface* 

(APIs)— provide*  an  ISO  9989  C  language  binding  to  the  language  independent  API  that  corresponds  exactly 
with  IEEE  Standard  1224,1. _ 

1327.2,  Directory  Service*  Application  Programming  Interface  (API)  -  C  Language  Specification  defines  a  C 

language  API  to  a  directory  service  Including,  but  not  necessarily  limited  to,  ITU-TS  X.S00  functionality _ 

Pi  328,  Test  Methods  for  Measuring  Conformance  to  OSI  Abstract  Data  Manipulation  C  Language  Interfaces  - 
BMng  for  API— define*  the  test  methods  to  be  used  to  measure  conformance  to  IEEE  Standard  13?7 _ 
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Table  39.  (Coal’d) 

Pi  328.1,  Test  Methods  for  Measuring  Conformance  to  X.400  Bated  Electronic  Massaging  C  Language  Interfaces 
•  Binding  (or  Application*  Program  Intsrfscss  (API*)— datinaa  tha  tact  msthods  to  b*  used  to  maaaur* 
conformanca  to  IEEE  Standard  1327.1 

Pi  328.2,  Test  Methods  for  Directory  Services  Application  Programming  Interface  (API)  •  C  Language 
Specification— defines  the  general  requirement*  and  test  methods  tor  measuring  conformance  to  IEEE 
Standard  1327.2 _ 

Pi  372.  POSIX.  Part  1:  System  Application  Program  Interface  (API) (Language  Independent)  is  a  new  POSIX  API 
effort. 


Source:  'Applications  Portability  and  Open  Systems  Environments:  Status  Report*  presented  by  Ftogar  J.  Martin, 
NIST.  10th  APP/OSE  Workshop.  NIST,  Gaithersburg.  Maryland,  November  1892;  updated  from  IEEE  PAR* 
included  in  a  letter  from  Wiliam  Rhinehuis,  Chairman,  SPARC  and  Convenor,  OMC  to  Kenneth  Zemroweld.  Chair, 
X3T5, 1  December  1992  (X3T5/82-47B);  updated  from  (Ref .  APP 1993). 

15.1.3.4  X/Open  Common  Applications  Environment  (CAE) 

This  section  discusses  the  CAE  developed  by  the  X/Open  international  consortium  and 
specified  in  the  X/Open  Portability  Guide,  now  in  its  fourth  edition  (XPG4).  The  Portability 
Guide  recommends  standards  and  options  within  standards  to  achieve  an  open  environment  in 
which  new  applications  can  be  ported  without  modification.  Several  international  consortia  have 
endorsed  the  X/Open  CAE  as  a  basis  for  developing  open  environments. 

The  foundations  of  the  X/Open  CAE  are  the  interfaces  of  the  UNIX  System  V  operating 
system,  as  defined  in  the  AT&T  System  V  Interface  Definition  (SVID).  and  the  C  language.  The 
X/Open  CAE  consists  of  features  grouped  in  seven  functional  areas:  operating  system  and 
languages,  data  management,  user  interface,  general  interworking,  mainframe  interworking.  PC 
interworking,  and  media. 

XPG4,  October  1992,  addresses  the  following  [Ref.  OSN  1992k]: 

•  X  Windows  system 

•  Byte  stream  file  transfer  (BSFT)  protocol,  which  refers  to  ISO  8571  and  provides  a 
link  between  Internet  FTP  and  FT AM 

•  X.400  electronic  messaging  specifications 

•  X.500  directory 

•  NFS 

•  IBM’s  CPI-C  communications  interface 

•  PC- NFS  server,  based  on  Sun’s  protocols 

•  Local  Area  Network  Manager  (LMX)  for  PC  interworking,  based  on  Microsoft’s  LAN 
Manager  for  UNIX  protocols. 

Table  41  shows  the  XPG4  components  and  standards  for  the  seven  functional  areas. 
Standards,  dc  jure  and  dc  facto,  where  specified,  are  also  shown. 
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Table  40.  Stability  of  Applications  Portability  Standards 


OPBtATWG  SYSTEM  SERVICES 

Pwtafeta  OpwaHng  Syatam  Martaea  for  Consular  Emtoonmanta  (WPS  PUP  151-2) 
MST  Ptamad  FIPS  PUB  on  POSW  Stwl  and  UNMy  AppleaAona  Maifaoa  tar 
Computar  OpataUng  Oyataw  CnWonnianlaflgE  10012,1902) 

Amandnant  1:  RaaMma  Ertandon  (IEEE  P1003.4) 

Gnourily  InMao*  forth*  PortsMi  Opining  Synfom  Infoffoc*  lor 

Consular  EnvwonwanU  (IKE  PI 003.8) 

STR 

• 

FTR 

• 

• 

GAP 

HUMANCOMPUTER  MTERFACE 

SERVICES 

Uaar  Maitoo  Consonant  of  Applcatfona  PortaM*  ProMa  (FIPS  PUB  1SS-1) 

CEEP1296.1 

• 

SOFTWARE  ENGMEERMG 

SERVICES 

Ada  (FTPS  PUB  110) 

• 

C  (BPS  PUB  WO) 

COBOL  (FIPS  PUB  021-3) 

FORTRAN  (FFS  PUB 080-1) 

PMoal  (FIPS  PUB  100) 

• 

ECMA  FextUda  Common  TooM  Dwironmant  (PCTE) 

• 

DATA  MANAGBCNT  SERVICES 

Momaton  Raaawoa  Dfcfanny  Syatam  (IRDS)  (FIPS  PUB  158) 

m 

Palatian  languapa  SQL  (FIPS  PUB  127-1) 

m 

namola  Databaaa  Acoaaa  (RDA) 

• 

DATA  MTERCHANQE  SERVICES 

m 

ISO  M1&  1080 

SlanddMl  Paga  Daaciip8on  Languaga  (8POL)  (DIS 10180) 

• 

Standnd  Qanaiataad  Mndup  Languaga  (SGML)  (FH*S  PUB  152) 

m 

Etaotonfe  Manuaedpt  PiaporaMon  and  Mnfcup  (B0P%t)  (ANSMNSO  Z30J0-18M) 

OompulBr  QmoNm  MaMBa  (COM)  (FV8  PUB  121) 

m 

— - «,  i-m-i  A__u.  ** - ,m  -»* —  /IACQ\ 

rMWO  »  nmBI  W^nIC  CAE opmMmmmm  (MC9/ 

m 

Slandaid  tar  *m  Eaohanga  ol  Produel  Modal  Data  (STO).  ISO  CD  10803 

• 

ElacPanlc  Data  Intamhanga  (EDI)  (FIP8 181) 

• 

SpaOal  Data  Tnnalar  SpaoMeadon  (S0TP)  (FIPS  173) 

• 

QRAPHIC8  SERVICES 

GaapNoal  Kamal  Syatom  (OKS)  (FIPS  PUB  120-1) 

• 

Prognanmai'a  HMaanNoal  ManetMa  GnpNca  9yatam  (PtSQS)  (FVS  PUB  153) 

• 

NETWORK  S8TVICES 

CEE  P1003.12  PwtocoHndapondanl  Martaoaa  (PH) 

• 

EC  P1238  OSI  API 

• 

CEEP1238.1  FOa  Tianatar  Acoaaa  and  Man^awam  (FTAM)  API 

• 

aoa»»  Vanlon  2  (FIPS  UtM) 

• 

ISON  API 

• 

ISON  Paataeola 

• 

OSF  OCE  Ramota  Proooduro  CM 

• 

CEE  PIOIMJ  Tronapnant  Fla  Acoaaa 

• 

Qnromroonl  Natawdc  Managamant  Pro  8a  (QNMP)  (FTPS  170) 

m 

CEE  P12SM.1  X.400  Etactmnie  Maaaaging  API 

• 

CEE  P12242  X.800  DtroaMn,  Sandcaa  API _ 

• 

nCW  **  fW  t/«t  WlSffMNrff  flJSWI!  C3fMRVvRlnt  new  \JSS£/1, 

Kay:  Varaion  2.0,  MST,  US  OapaWnantof  Commam,  May  1983,  UNCLASSCCD. 

STR  8Magic  now  (aalaSvaly  aSMa). 

FTR  Otraia  jii.  in  <ha  Mura  (autojact  to  changa  but  flawing  atwdantzadon). 

GAP  NonSlniMlB  (ahMMISD  IMMKMI  not  ^  Waat  *a—  alaiMilaiil 
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Table  41.  XPQ4  Compoiwnti  mmI  Standards 


Subject  Area 

Components 

m  m  1 1 

Operating  System  and 

Internationalized  System  Cals  and 

Languages 

Ubraries 

Commands  and  Utilities 

ISO  9945*2:1992  (POSIX.2) 

C Language 

ISO  9899:1990 

COBOL 

ISO  1989:1985, 1989/AMI 

Pascal 

ISO  7185:1983 

FORTRAN 

ISO  1539:1980 

Ada 

ISO  8652:1977 

Date  Management 

ISAM 

Da  facto  industry  standard  C-ISAM  by 
Informix  Corporation 

Relational  Database 

ISO  9075:1992  (SQL) 

User  Interface 

X-Wmdow  System  Display 

X-Window  Services  to  Applications 

Terminal  Interfaces 

General  Interworking 

IS^  10607,  ISO  8571 

X.400  Gateway 

rru-Ts  x.400 

X.400  Message  Access 

rru-Ts  x.4oo 

Directory  Access 

Network  File  System 

ISO  9594  (ITU-TS  X.500) 

Transport  Service 

X/Open  Transport  Interface  (XTI) 

Mainframe  Interworking 

CPI-C 

IBM  CPI-C.  Version  1  “  — — — ^ 

PC  Interworking 

PC  (NFS  Server)  — 

LMX  Server 

Media 

XPG4  provides  components  that  can  be  separately  branded  or  collected  together  to  match  a 
profile.  An  XPG4  Component  is  the  smallest  unit  that  can  be  branded.  The  Internationalized 
Systems  Calls  and  Headers  within  the  Operating  System  and  Programming  Language  subject  area 
broadly  corresponds  to  ISO  9945-1:1990  (POSIX.1).  However,  the  ISO  standard  defines  only  a 
subset  of  the  operating  system  interfaces  required  by  applications  developers  and  also  allows  for 
some  optionality  and  alternative  behavior.  The  X/Open  System  Interfaces  remain  that  of  a 
complete  operating  environment  and  contain  many  additional  interfaces  and  features.  To  satisfy 
internationalization  requirements,  X/Open  Systems  provide  full  data  transparency  to  applications, 
allowing  flexibility  in  the  choice  of  coded  character  set(s).  In  addition,  the  system  must  allow 
program  messages  to  be  handled  in  the  native  language  of  the  user,  as  well  as  provide  culture- 
dependent  data  items.  Internationalization  activity  has  been  concentrating  on  the  support  of  Eastern 
languages  and  cultural  differences,  and  of  multi-byte  code  sets  in  general. 

Data  management  includes  Indexed  Sequential  Access  Method  (ISAM)  interfaces  that  are 
defined  for  creating,  managing,  and  manipulating  indexed  files,  and  SQL  for  access  to  relational 
database  management  systems.  The  ISAM  definition  is  based  on  Version  2.10  of  C-ISAM  by  the 
Informix  Corporation.  SQL  is  based  on  ISO  9075:1992  but  contains  extensions  and  deviations 
(sec  Section  6.2.2.2). 

User  Interface  work  within  the  X/Open  environment  covers  X/Open  Window  Management 
Specifications  for  the  X  Window  System  Protocol,  X  Toolkit  Intrinsics,  and  Inter-client 
Communications  Conventions  Manual.  The  Xlib  interface  has  been  brought  up  to  the  X  Window 
System  4  release  level. 

One  of  X/Opcn 's  major  objectives  is  to  facilitate  effective  interworking  between  X/Open- 
compliant  systems.  The  XPG4  Transport  Service  is  an  update  to  the  XPG3  component,  with 
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modifications  and  extensions,  particularly  in  the  area  of  option  management,  and  in  the  addition  of 
support  for  NetBIOS. 

In  the  area  of  PC  interworking,  XPG3  provided  support  for  the  use  of  workstations  and 
personal  computers  as  terminals  connected  to  open  systems  using  asynchronous  serial  links  with 
terminal  emulation  and  file  transfer.  X/Open  has  replaced  these  facilities  to  provide  for  file  access 
and  print  services.  The  XPG4  (PC)  NFS  component  defines  the  NFS  protocols  that  must  be 
supported  by  an  X/Open-compliant  system  in  order  to  act  as  a  file  and  print  server  to  a  network  of 
DOS-based  personal  computers.  The  XPG4  LMX  server  component  defines  the  LMX  protocols 
that  must  be  supported  by  an  X/Open-compliant  system  in  order  to  act  as  a  file  and  print  server  to  a 
network  of  DOS-based  personal  computers. 

One  of  the  major  problems  inhibiting  the  porting  of  applications  between  X/Open  Systems 
is  that  of  incompatible  media  and  the  physical  problems  of  transferring  source  code  in  machine- 
readable  form.  Common  specifications  were  defined  in  XPG3  as  "Source  Code  Transfer."  The 
media  definitions  in  the  Source  Code  Transfer  component  of  XPG3  have  been  updated.  The 
physical  size/shape  and  the  recording  format  are  described.  Provisions  for  1600  bpi  and  6230  bpi 
magnetic  rapes  are  carried  forward,  but  5.25-inch  and  3.5-inch  720-Kbyte  floppy  discs  are  no 
longer  mandated.  [Ref.  X/Open  1992] 

15.1.3.5  Open  Software  Foundation  (OSF)  Profiles 

OSF  has  announced  an  API  specification  called  the  Application  Environment  Specification 
(AES).  The  RPC  AES  was  printed  by  Prentice  Hall  in  October  1993.  Hie  time  service  AES 
material  has  been  reviewed  by  X/Open,  with  the  directory  service  currently  undergoing  X/Open 
and  OSF  member  review.  Security  and  threads  AES  sections  are  making  good  progress;  OSF 
expects  to  have  these  sent  to  X/Open  for  review  by  the  end  of  1993.  Distributed  Hie  System 
(DFS)  AES  material  will  be  developed  in  1994.  X/Open  will  include  these  in  XPG  specifications. 
These  AES  sections  will  complete  Revision  A  of  the  AES,  which  corresponds  to  1.0 JX.  OSF  will 
update  these  with  1.1  features  to  produce  Revision  B  when  1.1  products  are  in  the  marketplace. 

Revision  1.1  is  to  be  expected  to  be  available  in  the  third  quarter  of  1994.  It  will  have 
extensions  in  the  area  of  security,  internationalization,  and  serviceability  as  well  as  better 
interoperability  with  Microsoft  RPC  clients. 

OSF  is  managing  a  group  on  behalf  of  X/Open  to  specify  an  extensible  architecture  for 
integrating  name  directory  servers.  This  project  is  known  as  the  Federated  Naming  project  It 
includes  technical  participation  from  OSF,  HP,  SunSoft  SNI,  IBM  and  Banyan,  and  one  or  two 
additional  participants  are  expected  before  the  project  is  completed.  The  output  of  this  project  will 
be  an  API  specifying  a  programming  interface  suitable  for  use  with  directory  servers  that  are  used 
to  compose  a  namespace  at  runtime,  along  with  a  protocol  that  can  be  exported  by  directories  that 
wish  to  participate  in  the  namespace.  (It  may  be  considered  a  backplane  for  directory  integration.) 
It  does  not  increase  interoperability  of  directories,  although  it  provides  a  methodology  for  others  to 
accomplish  this.  As  part  of  this  project,  the  participants  will  prototype  this  API  over  a  variety  of 
existing  directory  services,  including  CDS,  NIS+,  and  X.500.  OSF  expects  to  incorporate  this 
API  in  a  future  version  of  DCE  (see  Section  13.4.1)  to  allow  additional  directory  servers  to 
participate  in  the  DCE  global  name  space.  X/Open  will  publish  and  revise  the  resulting 
specification.  The  group  has  a  draft  API  specification  suitable  for  beginning  the  prototyping  effort. 
The  prototype  effort  will  require  a  few  months  to  develop  and  assess,  with  resulting  changes  to 
the  specification  incorporated  at  its  conclusion. 
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The  Open  Systems  Foundation  Research  Institute  is  also  working  on  an  architecture-neutral 
distribution  format  (ANDF).  This  project  promises  to  produce  a  methodology  that  can  assure 
application  portability  without  requiring  access  to  source  code.  The  specification  and  technology 
will  permit  compilation  of  the  source  to  an  intermediate  form  that  is  distributed  to  users.  The  user 
will  install  the  intermediate  form  by  compiling  it  to  final  form  for  each  platform.  Assuming  that  a 
platform  is  replaced  by  another,  the  intermediate  form  could  be  recompiled  for  the  new  platform. 
ANDF  use  assumes  the  existence  of  an  "installer”  for  the  platform  to  be  used;  it  also  assumes  that  a 
standardized  library  and  set  of  APIs  exist  on  each  platform. 

The  base  technology  for  ANDF  comes  from  the  United  Kingdom's  Defense  Research 
Agency  (DRA).  DRA  plans  to  commercialize  this  technology.  An  experimental,  non-commercial 
release  is  expected  by  the  first  quarter  of  1994.  Commercial  release  is  expected  in  the  second 
quarter  of  1994.  ESPIRIT  projects  in  1995  should  produce  additional  products. 

15.1.3.6  Technical  and  Office  Protocol  (TOP) 

The  TOP  is  part  of  a  combined  industrial  and  government  effort  on  the  part  of  users  in  the 
office  and  engineering  community  to  specify  a  profile  of  standard  protocols  that  can  be  used  in 
commercial  applications  to  provide  connectivity  and  interoperability.  TOP  is  associated  with 
another  effort.  Manufacturing  Automation  Profile  (MAP)  (see  Section  9.1 1.5.1). 

The  TOP  specification  [Ref.  Thacker  1987]  defines  a  functional  network  for  distributed 
information  processing  for  technical  and  business  functions.  TOP  Version  1.0  (November  1985) 
provides  for  Carrier  Sense  Multiple  Access/Collision  Detection  (CSMA/CD)  and  Token  Bus  LANs 
using  the  connectionless  or  X.25  Internet  Protocol  and  the  Class  4  transport  protocol,  with  FT AM 
supported  at  Layer  7. 

TOP  Version  3.0  was  released  in  1989,  and  it  is  expected  to  have  a  six-year  stability  period 
before  release  of  another  version.  It  provides  not  only  FT AM  but  also  VT,  Directory  services, 
network  management,  and  MHS  at  Layer  7.  It  further  includes  the  ODIF  (ISO  8613),  Computer 
Graphics  Metafile  (CGM)  Interchange  Format  (ISO  8632),  Product  Definition  Interchange  Format 
(PDIF),  and  the  GKS  interface  (ISO  7492).  IGES  Version  3.0  from  ANSI  [Ref.  ANSI 
Y14.26M-1986,  IGES  1986]  is  included.  At  the  lower  layers,  TOP  Version  3.0  provides  for 
Token  Ring  LANs  and  for  X.25  packet  switching  via  X.21  and  X.21  bus  at  Layer  1.  TOP 
Version  3.0  is  summarized  in  Table  42.  Future  editions  of  TOP  are  expected  to  point  to  IGOSS 
(see  Section  16.1.3.3). 

The  international  organization.  Open  Systems  Interconnection  for  Technical  and  Office 
Protocol  (OSITOP),  has  been  examining  architectural  issues  and  has  produced  a  position  paper  on 
a  solution  for  connection-oriented  network  service  (CONS)  and  connectionless-oriented  network 
service  (CLNS)  internetworking  (see  Section  9.12).  This  paper  reaches  the  following  conclusions: 

•  It  is  not  realistic  to  sidestep  the  CONS  vs.  CLNS  issue  by  expecting  that  one  of  the 
two  incompatible  sets  of  protocols  (CONS  or  CLNS)  be  abandoned  or  by  accepting 
the  existence  of  two  non-communicating  OSI  islands. 

•  Three  solutions  are  valid,  although  not  architecturally  correct  according  to  OSI 
principles: 

The  "265”  internetworking  function  (based  on  TP4  over  CONS) 

A  Distributed  System  Gateway  (DSG) 

A  Multi-System  Distributed  System  Gateway  (MSDSG). 

•  OSITOP  recommends  the  MSDSG  solution. 
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Tabla  42.  Standard*  for  TOP  Version  3.0 


HOLC  (LAPD):  High  Laval  Data  Link  Control  (Link  Accsm  Procedure  VareionD) 


15.1.3.7  Multivendor  Integration  Architecture  (MIA) 

Nippon  Telegraph  and  Telephone  Corporation  (NTT)  has  announced  the  introduction  of  its 
Multivendor  Integration  Architecture  (MIA).  The  architecture,  developed  together  with  NTT  Data 
Communications  Systems  (NTT  DATA)  and  five  computer  vendors  (IBM  Japan.  Digital  Japan, 
NEC,  Hitachi,  and  Fujitsu),  will  enable  the  creation  of  systems  composed  of  different  vendors' 
computers.  The  architecture  has  been  developed  with  die  intention  of  providing  a  multivendor 
system  that  users  will  find  easy  to  use.  The  information  processing  system  software  consists  of  an 
operating  system  with  user  programs,  databases,  and  interface  programs  installed  for  connecting 
terminals  and  other  equipment  In  developing  MIA,  preference  was  given  to  international 
standards  such  as  program  language  specifications  and  communication  protocols  that  have  been 
time-tested.  In  areas  that  have  not  yet  been  standardized,  the  emphasis  was  on  determining  what 
would  be  necessary  from  the  user's  standpoint  In  adopting  the  specification,  efforts  were  focused 
on  either  expanding  the  international  standards  or  on  adopting  de  facto  standards  and  specifications 
proposed  through  joint  research.  MIA  consists  primarily  of  three  interfaces  common  to  vendors 
[Ref.  OSN  1991a]: 

•  Application  Program  Interface  (API).  The  interface  located  between  basic  software 
and  application  programs  that  sets  the  specifications  for  three  programming  languages 
(COBOL,  FORTRAN,  and  C)  and  the  database  language  SQL,  based  on  ISO  and 
ANSI  standards.  An  interface  called  the  Structured  Transaction  Definition  Language 
(STDL)  was  newly  specified  for  the  communication  access  interface  and  user  access 
interface  for  distributed  transaction  processing. 

•  System  Interconnection  Interface  (SII).  This  prescribes  a  communication  protocol 
consisting  of  four  types  of  upper-layer  protocol  specifications:  file  transfer,  mail 
transfer,  distributed  transaction  processing,  and  network  management  The  lower 
layer  protocol  specifications  are  also  prescribed  based  on  Internet  and  OSL 
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•  Human  Interface  (HUD.  MIA  uses  three  types  of  human  interface  specifications  from 
OSF/Motif.  OPEN  LOOK,  and  IBM's  Common  User  Access  (CUA).75  These  three 
interfaces,  which  are  becoming  industry  standards,  are  used  with  UNIX  and  IBM's 
OS/2. 

15.1.3.8  EWOS  Profiles  for  the  Open  System  Environment  (OSE) 

EWOS  has  been  studying  the  application  of  profiling  concepts  to  the  domain  of  OSE  since 
it  proposed  (ENV  40002)  to  create  European  functional  standards  for  the  CAE  (see  Section 
15. 1 .3.4).  ENV  4(XX)2  applies  the  methodology  for  OSI  profiles  to  the  CAE  domain,  so  that  the 
use  of  the  corresponding  base  standards  could  also  be  specified  in  a  similar  way  for  use  in 
procurement. 

EWOS  has  issued  a  draft  document  on  OSE  profiles  (EWOS/TA/91/68,  April  1991).  The 
document  covers  the  use  of  standards  in  a  number  of  broad  domains: 

•  User  access  techniques 

•  POSIX  interfaces  (ISO  9945) 

•  APIs  to  system  and  information  services 

•  Data  formats  for  storage  and  interchange 

•  OSI  protocol  profiles 

•  Application  development  tools,  languages,  and  bindings 

•  Internationalization. 

If  approved,  it  would  be  forwarded  to  ISO's  SGFS  for  functional  standardization. 
Table  43  shows  the  proposed  taxonomy  for  OSE  profiles. 

15.1.3.9  UNIX  International  s  ATLAS  (UI-ATLAS) 

UNIX  International  recently  announced  its  UI-ATLAS  Distributed  Computing  Program 
that  has  the  support  of  20  companies.  UI-ATLAS  is  designed  to  meet  five  challenges  to  the  open 
systems  industry  [Ref.  UNIX  1991]: 

•  Provide  a  framework  for  systems  software  beyond  the  operating  system  level  that 
delivers  a  complete  open  systems  environment 

•  Provide  a  model  for  allowing  alternative  technologies  through  standard  interfaces 
(APIs,  protocols,  and  data  formats)  without  loss  of  investment 

•  Interoperability  with  the  installed  base  of  computer  systems  to  protect  customer 
investments. 

•  Harmonize  the  industry's  diverse  approach  to  open  systems  technology  by  allowing 
the  implementation  of  competitive  technologies  under  a  single  framework. 

•  Provide  a  new  paradigm  for  distributed  applications  that  uses  object  orientation  to 
better  manage  the  complexities  inherent  in  heterogeneous  distributed  computing. 

15.1.3.10  Desktop  Management  Interface  (DMI) 

DMTF's  (see  Section  15.1.2.6)  DMI  is  a  set  of  APIs  for  managing  desktop  systems.  The 
DMI  architecture  was  announced  in  August  1992  and  the  specifications  are  expected  to  be  released 
as  a  reference  document  later  in  1993.  Beta  code  was  shipped  to  group  members  in  May  1993, 
including  test  implementations  of  the  interface,  and  managed  objects  for  hardware,  software,  and 
add-in  components.  Compatibility  issues  have  been  considered  and  the  group  will  produce 
application  software  that  tests  compliance.  So  far  the  work  has  focused  on  IBM-compatible  PCs, 

7  5  CUA  is  the  user  interface  portion  of  IBM's  Systems  Application  Architecture  (SAA). 
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but  the  architecture  can  be  ported  and  DMTF  encourages  future  support  for  the  Macintosh  and 
UNIX.  The  final  reference  kit  will  include  the  API  definitions,  a  local  test  application,  and 
Windows  and  DOS  versions  of  the  service  layer  code.  Reference  documents  and  code  will  be 
available  free  of  charge  from  any  of  the  eight  DMTF  founders.  DMTF  expects  a  market  in  DMI- 
compliant  products  to  develop  in  the  next  2  years.  IBM  is  investigating  incorporating  it  into  the 
AIX,  OS/2,  and  DOS  operating  systems.  Microsoft  plans  to  incorporate  DMI  into  DOS, 
Windows,  and  NT.  Intel  will  include  DMI  compliance  in  the  next  version  of  its  LAN  adapters, 
and  management  products.  [Ref.  OSN  1993g] 

Table  43.  EWOS  Profiles  for  tha  Open  System  Environment 


POEnn 

Open  System  Environment  Profiles  j 

POEO 

Base  Environment 

POE1 

Workstation  Environments 

POEIO  Terminal  Environment 

POE1 1  Personal  Workstation  Environment 

POE  12  Professional  Workstation  Environment 

POE2 

Utility  Server  Environments 

POE20  Electronic  Message  Senring  Environment 

POE21  Directory  Serving  Environment 

POE22  Access  Control  Serving  Environment 

POE3 

Information  Server  Environments 

POE30  DBMS  Server  Environment 

POE31  Document  Senring  Environment 

POE4 

Transaction  Processing  (TP)  Environments 

POE40  Simple  TP  Environment 

POE41  Enhance  TP  Environment 

POE  5 

Real-time  Environments 

POE50  Real-time  Environment,  seconds 

POE51  Real-time  Environment,  mifliseconds 

POE6 

Supercomputing  Environments 

POCaa 

Open  System  Environment  Components  j 

POCA 

Application  Program  Interfaces 

POCAM  APIs  for  Management  Services  (e.g.,  APIs  to  access 

and  manipulate  managed  objects) 

POCAU  APIs  for  End-User  Services  (e.g.,  FIMS  API) 

POC  AS  APIs  for  System  Services  (e.g.,  ISO  9945-2) 

POCAI  APIs  for  Information  Services  (e.g.,  ISO  9075.2) 
POCAC  APIs  for  Communication  Services  (e.g.,  X.400  API) 

POCL 

Look-and-Feel  Definitions 

POCF 

Formats 

POCP 

Protocols 

POC:  Profiles  for  Open  System  Environment  Components 
POE:  Profiles  for  Open  System  Environments 


15.1.3.11  Service  Providers  Integrated  Requirements  for  Information 
Technology  (SPIRIT)  Project 

The  SPIRIT  Project  [OSN  1993t]  is  developing  a  telecommunications  service  providers' 
(Telcos)  procurement  specification  for  a  general  purpose  computing  platform.  The  project,  which 
started  in  mid-March  1993,  includes  AT&T,  Bellcore,  BT,  ETIS,  France  Telecom,  KDD,  NTT, 
STET  and  Telefonica.  It  aims  to  define  a  common  specification  and  has  released  the  first  version. 
The  project  will  run  for  2  years,  and  the  work  will  proceed  in  three  phases: 
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•  Phase  A  compared  the  existing  documents  of  the  service  providers,  to  derive  a 
statement  of  common  components. 

•  Phase  B  will  progress  phase  A  selections  and  select  emerging  technologies 

•  Phase  C  will  concentrated  on  producing  requirements  for  newer  technologies. 

15.2  Applications  Programming  Interfaces  (APIs) 

APIs  define  the  interface  to  communications  and  other  services.76  Programs  that  use  them 
will  be  more  portable,  able  to  work  with  other  services,  and  run  in  other  environments.  APIs 
serve  to  decrease  the  need  for  platform-specific  application  programming.  Although  APIs  are 
outside  the  original  scope  of  the  OSI  standardization  scheme,  many  groups  are  defining  APIs  for 
various  communications  services  within  the  OSI  program.  A  November  1993  Information  Week 
article  [Ref.  Stahl  1993)  characterizes  APIs  as  one  type  of  middleware ,  go-between  software  that  is 
crucial  to  distributed  computing  (see  Section  13.5). 

Vendor-Independent  APIs,  Figure  17  shows  a  vendor-independent  set  of  APIs  for 
the  OSI  environment  Some  of  the  vendor-independent  APIs  defined  by  several  consortia  or 
groups  for  the  OSI  environment  include: 

•  Manufacturing  Automation  Protocol  (MAP)  3.0 

Connection  Management  Interface  Specification  ( CM-1S) 

Private  Communication  Application  Interface  Specification 

-  FTAM  API 

MMS  API  (see  Section  9.1 1.5.1) 

•  UNIX  International 

ACSE/Presentation  Layer  Interface  ( API ) 

Transport  Layer  Interface  (TU)  and  the  Transport  Layer  Protocol  Interface  (TPI) 
Network  Layer  Interface  (NU)  and  Network  Protocol  Interface  (NPI) 

Data  Link  Protocol  Interface  (DLPI) 

•  X.400  Applications  Programming  Interface  Association  (XAPIA  and  X/Open) 

X400  API  Specification  (X.400) 

X.400  Gateway  Specification 
OSI  Object  Management  API  (XOM) 

•  X/Open 

X/Open  Transport  Interface  API  (XT!) 

X/Open  ACSE/Presentation  Service  API  (XAP) 

X/Open  Common  Programming  Interface-Communications  (CPI-C) 

X/Open  Directory  Services  API  (XDS) 

-  X/Open  FTAM  API  (XFTAM) 

•  IEEE 

P1003.8,  Transparent  File  Access 

P 1 003. 1 2,  Protocol-Independent  Interfaces 

P1003. 17,  Namespace  and  Directory  Services 

P 1 224,  API  to  Management  Functions  for  ASN.  I  Objects 

P1224. 1 ,  API  to  ITU-TS  X.400  User  Agent  and  Message  Transfer  Agent 

PI  224.2,  Directory  Services  Application  Programming  Interface  (API)  - 

Language  Independent  Specification 


76  Discussion  taken  from  ’A  Users'  Guide  to  Data  Communications  APIs."  by  Eric  Fleishman,  OSN:  The  Open 
Systems  Newsletter,  vol.  6.  nos.  5  and  6.  June  and  July  1992  issues. 
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P1238,  API  to  Common  OSI  Connection  Management  and  Support  Functions 
-  P1238.1,  API  to  FTAM 

PI 326,  Test  Methods  for  Measuring  Conformance  to  OSI  Abstract  Data 
Manipulation  -  API 

P1326. 1,  Test  Methods  for  Measuring  Conformance  to  X.400  Based  Electronic 
Messaging  Application  Program  Interfaces  (API)  [ Language  Independent] 
P1326.2,  Test  Methods  for  Directory  Services  Application  Programming 
Interface  (API)  -  Language  Independent  Specification 
P1327,  OSI  Abstract  Data  Manipulation  API 

P1327.1,  X.400  Based  Electronic  Messaging  C  Language  Interfaces  -  Binding 
.  for  Applications  Program  Interfaces  (APIs) 

P1327.2,  Directory  Services  Application  Programming  Interface  (API)  -  C 
Language  Specification 

P1328,  Test  Methods  for  Measuring  Conformance  to  OSI  Abstract  Data 

Manipulation  C  Language  Interfaces  -  Binding  for  API 

P1328.1,  Test  Methods  for  Measuring  Conformance  to  X.400  Based  Electronic 

Messaging  C  Language  Interfaces  -  Binding  for  Applications  Program  Interfaces 

(APIs) 

PI 328.2,  Test  Methods  for  Directory  Services  Application  Programming 
Interface  (API)  -  C  Language  Specification. 

P1003.12  will  provide  a  portable  interface  to  both  high-level  and  low-level  transport 
services.  The  high-level  interface  is  referred  to  as  the  Simple  Network  Interface  (SNI);  the  low- 
level  interface  will  be  based  on  Berkeley  Sockets  and  the  X/Open  XTT.  P1238  provides  a  high- 
level  interface  to  ISO  upper  layer  services.  It  will  permit  developers  of  OSI  application  services 
such  as  message  handling,  FTAM,  Directory,  and  network  management  to  use  a  common  upper 
layer  platform  and  focus  development  efforts  on  the  application  services  themselves.  [Ref.  IGOSS 
1993] 

Data  Management  APIs.  Several  data  management  initiatives  will  define  APIs  (see 
Section  6.2.2.2).  ANSI  is  working  on  SQL3  as  a  future  API  for  conforming  database 
management  systems  (usually  relational).  The  SQL  Access  Group  and  X/Open  are  working  on  an 
API  and  SQL-standard  for  client-server  interactions.  Microsoft  has  produced  an  Open  Database 
Connectivity  (ODBC)  standard,  which  is  based  on  early  work  of  the  SQL  Access  Group  and 
X/Open.  Brained,  Novell,  IBM,  and  others  are  working  on  the  Integrated  Database  Application 
Programming  Interface  (ID API).  [Ref.  RNLA  1994,  p.  31] 

Messaging  APIs.  In  the  past,  there  has  been  considerable  confusion  over  which 
electronic  mail  API  users  and  developers  should  support.  Recently,  however,  Novell  Inc.'s 
Message  Handling  Service  (MHS)  API  has  eclipsed  competing  APIs  including  Lotus  Development 
Corporation's  Vendor  Independent  Mail  (VIM)  and  Microsoft  Corp.’s  Mail  Application 
Programmer  Interface  (MAPI)  and  has  emerged  as  the  most  popular  mechanism.  The  commercial 
vendor  community  is  standardizing  on  the  Common  Mail  Calls  (CMC)  specification  developed  by 
X.400  Application  Programming  Interface  Association  (XAPIA).  While  the  alignment  of  MAPI 
and  VIM  forces  is  good  news  for  users,  questions  remain  about  the  technology  on  which 
extensions  to  CMC  will  be  based  and  whether  key  vendors  will  continue  to  support  the  new 
interface  extensions.  [Ref.  Rash  1993] 
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Source:  *A  Users'  Guide  to  Data  Communications  APIs.*  Pt.  2,  by  Eric  Fleishman, 
OSN:  Tha  Opart  System *  Namlattar,  Voi.  6.  No.  6,  June  1M2,  p.  2. 


Key:  ACSE  —  Association  Control  Sendee  Element 

APIA  —  X.40Q  Applications  Programming  Interface  Association 
APU  —  ACSE/Preeentatton  Layer  Interface 
BSFT — Byte  Stream  File  Transfer 

COCMSF  —  Common  OSI  Connection  Manegement  and  Support  Functions 

CPI-C  —  Common  Programming  Interface -Communications 

DIPl  — « Data  Link  Protocol  Interface 

DNI—  Detailed  Network  Interface 

FT AM  —  FIs  Transfer,  Access  and  Management 

MAP  —  Manufacturing  Automation  Protocol 

MMS  —  Manufacturing  Man  apt  jpaciicitton 

NLPI  —  Network  Layer  Protocol  Interface 

NP1  —  Network  Protocol  Interface 

PU  —  Presentation  Library  Interface 

SNI  —  Simple  Network  Interface 

TU  —  Transport  Layer  Interface 

TPI  —  Transport  Layer  Protocol  Interface 

IM  —  Unix  Intemationai 

XAP  —  X/Open  ACSE/Presentabon  API 

XDS — X/Open  Directory  Services 

XOM— OSI  Object  Management  API 

XT!  —  X/Open  Transport  Interface 

Figure  17.  Vendor-Independent  APIs  for  the  OSI  Environment 

Long-Term  API  Standardization.  In  June  1992,  JTC1/SC21  initiated  a  study  period 
on  the  international  standardization  of  APIs  and  raised  the  following  short-  and  long-term 
considerations.  In  the  short  term,  SC21  notes  that  there  has  been  significant  intemationai  activity 
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and  agreement  on  the  development  of  three  particular  APIs:  (1)  the  MHS  API,  (2)  the  OSI 
Directory  API,  and  (3)  the  OSI  Abstract-Data-Manipulation  API.  Work  on  these  APIs  has  been 
progressed  in  the  X.400  API  Association,  X/OPEN,  and  IEEE  since  1988  and  is  mature  and 
widely  known.  Implementations  exist  based  on  these  specifications,  and  SC21  considers  that  this 
work  should  be  progressed  expeditiously  within  JTC1  and  anticipates  that  no  major  modifications 
will  be  needed. 

The  first  meeting  of  the  SC21  study  group  on  APIs  was  held  in  Boulder,  Colorado,  in 
November  1992.  There  was  strong  agreement  among  the  participants  on  the  importance  of  this 
subject  for  international  standardization  and  the  value  of  the  Reference  Model  of  Open  Distributed 
Processing  (ODP-RM)  to  guide  the  work.  Moreover,  it  was  agree  that  the  term  application 
programmatic  interface  (API)  is  misleading  because  one  person’s  application  is  another  person’s 
infrastructure.  It  was  agreed  that  a  programmatic  interface  that  is  subject  to  international 
standardization  should  be  called  a  standard  programmatic  interface  (SPI).  The  urgency  of  the 
public’s  need  for  standard  programmatic  interfaces  led  the  group  to  propose  that  SC21  shorten  the 
study  period  to  one  year  and  take  action  at  the  Yokohama  meeting.  The  output  of  die  meeting  was 
SC21  N  7425,  Draft  First  Report  on  the  New  Work  Area  on  Programmatic  Interfaces, 
November  1992.  [Ref.  SC21  N  7424  1992] 

In  June  1993  at  its  Plenary,  SC21  approved  SC21  N  8045  Revised,  The  Report  of 
Programmatic  Interfaces,  as  the  SWG-API  final  report.  This  report  concluded  that  there  was  a 
strong  requirement  for  standardization  of  programming  interfaces  and  a  need  for  a  framework  in 
which  the  work  could  be  carried  out.  During  the  June  1993  plenary,  SC21  dissolved  the  SWG- 
API,  and  agreed  to  establish  a  Special  Working  Group  on  the  Standardization  of  Programming 
Interfaces  (SWG-SPI).  The  output  of  the  November  1993  meeting  of  the  SWG-SPI  addressed  an 
architectural  framework,  technical  guidelines,  and  conformance  methodology.  [Ref.  SC21 N  8397 
1993] 

In  a  liaison  statement  of  December  1993,  the  SGFS  provided  the  following  notes  on  the 
further  investigation  of  APIs  in  relation  to  profiles  [SGFS  N 1087  1993]: 

•  The  SGFS  intends  to  define  (or  provide  provisions  for)  profiles  that  combine  APIs 
and  protocols  into  some  higher  level  of  profiles. 

•  An  API  does  not  directly  use  another  API.  The  functionality  offered  through  an  API 
may  use  another  API,  but  this  need  not  lead  to  a  fixed  relationship  between  APIs. 

•  Profiling  systems  in  such  a  way  that  one  functionality  invokes  another  through  an  API 
puts  constraints  on  the  implementation.  This  is  an  issue  when  exchanging  components 
of  a  profile,  but  it  is  not  relevant  for  application  portability  and  interoperability. 

In  September  1993,  the  OIW  raised  the  following  concerns  regarding  TR  10000-3  and 
distinguishing  between  application  portability  and  system  software  portability  [Ref.  SGFS  N  1065 
1993]: 

•  Changing  the  objectives  to  allow  system  software  portability  (application  platform 
decomposition)  fundamentally  conflicts  with  other  current  objectives  (implementation 
transparency  and  accommodation  of  new  technology). 

•  Such  a  change  in  objectives  is  out  of  scope  with  and  conflicts  with  the  agreed 
definition  of  Open  System  Environment  (The  Way  Ahead  [SGFS  N  402]). 
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•  System  software  portability  issues,  constituencies,  and  standards  are  very  different 
from  those  (elated  to  application  portability. 

•  It  is  important  that  ongoing  work  addressing  the  users’  need  for  application  portability 
not  he  delayed  while  issues  surrounding  system  softwaie  portability  arc  resolved. 

The  ( )IW  further  noted  that  the  EWOS  and  the  OIW  agree  that  the  world  needs  to  understand  how 
software  such  as  COBRA.  DCE,  TP.  and  databases  fit  together.  These  enabling  technologies  are 
considered  as  middlewarc — the  users  do  not  see  them  but  they  give  the  capability  to  accomplish 
user  tasks.  The  OIW  proposes  a  model  to  reflect  how  middleware  is  to  be  incorporated,  using  the 
model  of  the  IEEE  PI 003.0  draft  guide  as  a  basis.  Completion  of  the  model  should  not  disturb  the 
existing  OSE  consensus  on  methods  for  achieving  applications  portability  and  would  be  the  basis 
for  developing  new  concepts  for  application  software  decomposition. 

In  December  1993,  the  SGFS  developed  a  White  Paper  on  OSE  Profiling  Concepts  [Ref. 
SCil'S  N  10H9  1993|  that  discusses  the  issues  of  application  portability  and  interoperability  and 
addressed  the  longer-term  need  (expressed  by  some  national  bodies)  for  a  level  of  exchangeability 
of  software  components.  This  paper  is  designed,  in  part,  to  be  consistent  with  the  user-oriented 
view  contained  in  the  Software  Integration  Platform  Specification  provided  by  the  Petrochemical 
Open  Software  Corporation  |SGFS  N  I070|.  The  paper  notes  an  agreement  that  a  major  purpose 
of  OSE  profiling  (TR  10000-3)  is  the  preparation  of  application  platform  (AP)  profiles  that  specify 
the  behavior  of  APs  to  meet  user  requirements.  The  AP  is  viewed  as  a  black  box  and  the 
corresponding  AP  profile  specifies  its  behavior  in  terms  of  the  behavior  that  can  be  observed  at  its 
interfaces  and  the  relationship  among  the  behaviors  at  different  interfaces.  AP  profiles  for  an  AP 
entity  comprise  HCIs  (interactions  with  human  beings),  information  interfaces  (to  information 
service  entities),  and  communications  interfaces  (to  communication  service  entities).  Example 
elements  of  AP  profile  specifications  would  include  Motif,  style  guides,  and  XHRS  Windows  for 
HCI;  SQL.  RDA,  XTI,  and  mOSI  for  database  interfaces;  XTI  and  TA  51  for  lower  layer 
communications  interfaces;  and  POSIX  for  operating  system  interfaces.  Exchangeability  is 
modelled  as  a  property  of  a  software  element  such  that  it  can  be  placed  outside  the  AP  and  that 
interfaces  between  it  and  the  AP  can  he  defined  in  implementation  terms  (e.g„  as  APIs). 

In  a  January  1994  report  to  JTC1,  the  Chair  of  SC21  noted  a  two-pronged  approach 
recommended  by  the  SC21  Study  Group  on  APIs: 

•  Short-term  work  to:  ( I )  identify  candidate  specifications  for  programming  interface 
standardization  related  to  standards  for  which  SC21  is  responsible;  (2)  request  use  of 
new  work  item  proposals  and  fast-track  procedures  to  progress  these  specifications; 
and  (3)  request  submitters  to  identify  the  SC(s)  responsible  for  the  underlying  function 
and  the  programming  languagc(s),  state  whether  the  programming  interface 
specification  require  extensions  to  a  programming  language  or  service,  characterize  the 
expertise  required  to  develop  the  specification,  and  identify  relationships  of  the 
specification  work  to  other  work  of  the  various  SC(s)  involved. 

•  Long-term  work,  using  a  Joint  Working  Group  on  Programming  Interfaces 
administered  either  by  SC21  or  SC22,  to  produce  a  standard  covering  architectural 
framework,  technical  guidelines,  and  conformance  methodology. 

The  basis  for  the  January  1994  report  to  JTCI  was  the  June  1993  Report  of  the  SC21 
Study  Group  on  APIs  |SC2I  N  8045  Revised].  The  Study  Group  met  in  November  1992  and 
June  1993.  The  report  emphasized  the  central  role  of  effective  and  well-coordinated  standards  for 
programming  interlaces  to  the  growth  of  open  distributed  systems.  Without  such  standardization, 
integration  of  open  systems  components  on  each  vendor  platform  will  be  more  difficult  and 
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expensive;  business  application  software  will  be  developed  using  ad  hoc  proprietary  interfaces  with 
resultant  increase  in  costs  to  integrate  that  software  into  an  enterprise’s  systems;  development  of 
standard  applications  will  be  hindered;  distributed  applications  will  be  less  portable;  and  skills  of 
applications  programmers  will  be  limited  to  specific  platforms.  [Ref.  SC21  N  8045  Revised  1993] 

The  report  emphasized  programming  interface — an  interface  between  one  software 
component  and  its  supporting  infrastructure — over  API  because  the  term  “application”  has 
sometimes  been  interpreted  simplistically  to  mean  an  interface  between  a  business  application,  such 
as  an  order  processing  system,  and  an  operating  system,  such  as  is  described  by  POSIX  and 
because  the  applications  elements  for  an  infrastructure  may  become  the  infrastructure  for  other 
elements.  When  a  programming  interface  has  become  a  standard,  the  term  standardized 
programming  interface  (SPI)  would  be  used.  The  following  paragraphs  highlight  some  of  the 
concepts  expressed  in  the  Study  Group  report.  [Ref.  SC21  N  8045  Revised  1993] 

Requirements  for  Interface  Specifications.  An  interface  specification  specifies  the 
interactions  of  functional  components  of  systems.  It  identifies  the  operations  that  can  be  performed 
at  an  interface,  the  state  of  the  communicating  objects  affected  by  the  operations,  and  the 
circumstances  in  which  the  operations  are  appropriate.  In  addition,  a  specification  may  be 
structured  (e.g.,  using  the  concept  of  viewpoint)  to  reflect  a  number  of  different  design  concerns 
relating  to  specific  behavior,  consistency,  or  enterprise  policy.  High-level  descriptions  are  refined 
into  distinct,  specific  descriptions  of  the  detail  of  programmatic,  interworking,  or  other  forms  of 
interactions.  Thus,  an  interface  specification  will  consist  of  two  parts:  (1)  the  specification  of  the 
behavior  observable  at  the  interface  and  (2)  the  specification  of  the  context  within  which  the 
function  being  accessed  operates.  [Ref.  SC21  N  8045  Revised  1993] 

Programming  Interface  Specification  Framework.  A  framework  is  needed  to 
identify  and  position  interfaces  relative  to  one  another  and  to  describe  what  combinations  of 
interfaces  are  possible  and  meaningful.  The  framework  is  based  on  a  set  of  technical  concepts 
necessary  to  ensure  consistency  across  definitions  of  interface,  interaction,  state,  and  behavior. 
Standardized  interfaces  for  different  kinds  of  reference  points,  such  as  programmatic, 
interworking,  perceptual,  and  interchange  reference  points  and  enable  precise  specification  of 
relationships  that  may  exist  between  them.  [Ref.  SC21  N  8045  Revised  1993] 

Such  a  framework  needs  to  express  a  range  of  API  concepts.  APIs  may  conceal  much  of 
the  detailed  capabilities  of  a  function  or  may  allow  them  all  to  be  controlled  directly.  Some  APIs 
may  be  independent  of  which  services  support  them  and  may  allow  service  selection  to  be  based  on 
factors  expressed  in  such  user-oriented  terms  as  urgency,  security,  cost,  or  service  availability. 
Other  APIs  may  be  specific  to  a  particular  function.  The  framework  needs  to  address  whether 
there  should  be  a  limit  on  scope  of  the  functions  an  interface  may  describe — a  function  may  be 
described  either  as  a  traditional  programming  interface  or  as  an  object  providing  a  service.  [Ref. 
SC21N  8320  1993] 

From  the  OSI  perspective,  an  API  defines  a  real  interface,  invocable  by  a  real  process,  to  a 
collection  of  related  services  provided  by  one  or  more  finite  state  machines  that  implement  one  or 
more  OSI  (though  not  necessarily  standardized)  services.  A  framework  needs  to  identify  the 
relationships  of  these  APIs  to  the  underlying  service  services  and  structure  of  the  APIs  that  may  be 
derived  from  the  architecture  relating  these  underlying  services.  For  OSI,  a  real  open  system  may 
have  any  number  of  APIs,  all  of  which  are  directly  or  indirectly  defining  concrete,  language- 
oriented  access  methods  to  abstract  services  defined  by  (1)  one  or  more  standardized  OSI  service 
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definitions,  (2)  one  or  more  non-siandardized  OS!  service  definitions,  and  (3)  modifications  from 
control  functions  as  defined  in  ISO/I EC  9545.  Where  an  abstract  service  is  to  have  APIs  for  more 
than  one  programming  language,  there  should  also  be  a  language-independent  specification  of  the 
API  to  ensure  semantic  consistency  of  the  several  language-dependent  APIs.  A  language- 
independent  API  specification  indirectly  defines  the  language-dependent  access  method  to  the 
underlying  abstract  service.  [Ref.  SC21  N  8316  1993] 

Potential  Use  of  the  ODP  Reference  Model  (RM-ODP)  for  Interface 
Specification.  The  RM-ODP  defines  the  interface  concept,  interaction,  interaction  point, 
behavior,  and  state.  The  five  RM-ODP  viewpoints  (enterprise,  information,  computational, 
engineering,  and  technology)  can  be  used  to  identify  and  separate  general  concerns  that  may 
intervene  in  the  specification  of  an  interface.  The  Viewpoint  Languages  of  RM-ODP  potentially 
provide  a  single  interface  specification  technique.  For  example,  the  ODP  Computational  Language 
provides  the  means  to  define  interface  types  and  behavior  in  a  manner  independent  of  actual 
localization  of  interfaces  and  of  programming  languages.  Further,  the  Engineering  Language 
provides  a  general  structure  wherein  several  interfaces  are  identified  and  defined  and  services  may 
be  specified.  In  addition.  RM-ODP  provides  a  general  conformance  framework  that  identifies  the 
different  types  of  reference  points  that  may  coexist  in  an  open  distributed  system  and  discusses  the 
conditions  under  which  testing  a  system  that  claims  conformance  to  several  different  interface 
specification  standards  can  be  done.  Finally,  the  Architectural  Semantics  of  the  RM-ODP  provides 
an  interpretation  of  the  basic  concepts  associated  with  the  notion  of  interface  using  existing  formal 
description  techniques  standardized  by  SC21. 

Relation  to  IDNs.  Several  activities  are  being  carried  out  in  JTC1  that  can  eventually 
lead  to  standard  programming  interfaces  (SPIs).  These  include  Common  Language  Independent 
Data  Types  (1SO/IEC  11404),  Common  Language  Independent  Procedure  Calling  Mechanisms 
(SC22  N  1082),  and  RPC  Interface  Definition  Notation  (IDN;  DIS  11578-2).  When  mappings 
from  IDN  to  programming  languages  become  available,  interfaces  defined  using  IDNs  can  also  be 
expressed  in  the  form  of  a  derived  SPI  specification  with  language  bindings. 

15.3  Conformity  to  an  Open  System  Environment 

JTC1  has  established  a  Special  Working  Group  on  Conformity  Assessment  (SWG-CA) 
and  requested  (Resolution  19  of  the  Berlin  plenary)  a  joint  working  group  be  established  in  SC21. 
Conformity  assessment  for  open  systems  environments  is  of  interest  to  SC6,  SC7,  SC  18,  SC21, 
SC22,  and  SC29.  As  requested  by  JTC1  in  SC21  N  7713,  SC21  established  [SC21  N  2507]  a 
Joint  Working  group  as  WG9  on  Conformity  Assessment  Documentation,  with  the  mandate  to 
publish  a  technical  report  based  on  JTC1  N  2330  as  modified  by  JTC1  N  2303.  At  the  same  time, 
SC21/WG1  developed  a  new  work  item  proposal  for  an  Open  System  Assessment  Methodology, 
which  was  forwarded  to  JTC1  for  a  3-month  letter  ballot  in  July  1993.  The  initial  JTC1  ballot 
[JTC1  N  2612]  failed  to  win  support  of  the  re»  tired  number  (5)  of  national  bodies  (only  CA,  GE, 
IT,  and  UK  promised  active  participation  an*,  resources)  {JTC1  N  2773].  (Note:  Conformity 
assessment  in  connection  with  conformance  testing  is  addressed  in  Section  12.2.1.2.) 

The  liaison  statement  developed  by  SC21  and  circulated  to  JTC1,  SGFS,  EWOS,  OIW, 
and  AOW  characterizes  the  work  as  providing  a  unifying  terminology  and  general  concepts  for  a 
methodology  and  framework  for  assessment  of  open  systems,  covering  the  following  areas: 

•  ODP,  OSE  profiles,  network  management,  and  APIs 

•  Dc  facto  and  de  jure  standards  in  coexistence 
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•  Conformance  testing  and  performance  testing,  and  their  relationship  to  interoperability 
testing,  including  both  active  and  passive  testing  (see  Section  12.2) 

•  Use  of  both  testing  and  specification  checking  (checking  the  consistency  and  mutual 
compliance  of  a  set  of  specifications  that  a  system  claims  to  conform  to)  in  order  to 
gain  confidence  in  conformance  to  the  set  without  having  to  test  against  every  member 
of  the  set 

•  Points  of  control  and  observation  not  only  at  communication  interfaces,  but  also  APIs, 
human -computer  interfaces,  robotic  interfaces,  and  storage  media  interfaces. 

SC21  further  noted  that  the  proposed  project  was  clearly  of  interest  to  many  committees  of 
JTC1  and  that  it  would  provide  an  “umbrella”  of  common  terminology  and  concepts  to  inter-link 
the  more  detailed  testing  methodologies  of  OSI,  OOP,  POSIX,  etc.,  produced  by  individual 
committees.  Regional  workshops  were  included  because  of  their  interest  in  OSE  profiles. 
Industry  groups,  such  as  the  Internet  Society,  OMG,  and  X/Open,  were  also  included  and 
proposed  as  C-liaison  organizations. 


15.4  Assessment 

API  standards  are  needed  to  specify  common  methods  of  accessing  network  services  from 
programming  environments.  Examples  (from  the  NIST  APP)  are: 

•  API  for  protocol-independent  interfaces.  Draft  2,  Detailed  Network  Interface,  a  low- 
level  interface  specification,  has  been  completed  by  IEEE  P 1003. 12.  It  includes  the 
technology  of  the  XPG4  version  of  the  X/Open  Transport  Interface  and  die  Version 
4.4  BSD  sockets  interface.  It  does  not  yet  include  features  such  as  die  Simple 
Network  Interface  and  the  Naming  Interface,  which  would  be  included  in  a  later 
specification. 

•  Communication  API  for  QSI  services.  IEEE  P1238  has  been  developing  an  API 
between  applications  and  the  OSI  ACSE  and  presentation  services  (but  no  base 
document  has  been  agreed);  IEEE  approval  by  early  1994  is  expected.  A  separate 
activity  (IEEE  P1238.1)  is  developing  an  API  for  FT AM  implementations;  de  facto 
FT AM  API  products  are  available,  but  the  P1238.1  specification  is  not  expected  until 
late  1994. 

•  Communication  API  for  Integrated  Digital.  Video,  and  Voice.  An  application  software 
interface  (ASI)  for  ISDN  is  being  developed  to  standardize  access  and  administration 
of  ISDN  services  (provided  by  hardware  commonly  known  as  network  adapters). 
Version  1  of  the  ASI  was  produced  by  the  North  American  ISDN  Users’  Forum  in 
June  1992.  It  contains  only  a  limited  set  of  service  definitions.  Additional  work 
includes  device  control  and  an  additional  higher  level  interface. 

•  Electronic  messaging  API.  An  X.400- based  electronic  messaging  API  is  being 
developed  by  IEEE  P1224.1  (Draft  3)  that  defines  a  language-independent  interface 
between  the  user  of  a  mail  system  and  the  mail  system.  IEEE  approval  is  expected 
early  in  1993.  It  does  not  include  EDI  and  the  X.400  Message  Store  (expected  to  be 
treated  as  addenda  to  the  standard).  A  high-level  API  is  needed  and  may  be 
standardized  in  the  future. 

•  Directory  services  API.  IEEE  P1224.2  is  developing  (Draft  5  was  expected  in 
November  1992)  a  standard  directory  service  user  agent  interface  to  support 
application  portability  at  the  source  code  level.  It  is  language  independent  and 
designed  to  support  access  to  ITU-TS  X.500  functionality  as  well  as  to  other  directory 
services.  C  language  bindings  are  being  specified  (P1327.2). 
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16.  INTERNATIONAL  AND  NATIONAL  STANDARDIZED  PROFILES 

16.1  Profiles  of  OSI  Standards 

The  following  sections  provide  examples  of  the  profiles 
of  standards  being  considered  for  migration  toward  open 
information  system  environments. 

16.1.1  Workshops  Developing  OSI  Profiles 

Three  regional  international  workshops  have  been 
established  to  promote  OSI.  These  are  the  EWOS,  POSI 
(Promoting  Conference  for  OSI) — the  Asia/Oceania  Workshop 
(AOW),  and  the  OSE  Implementor's  Workshop  (OIW).  The 
OIW  is  hosted  by  NIST.  A  similar  group,  IIW  (see  Section 
9.7.6)  develops  profiles  for  ISDN. 

A  Regional  Workshop  Coordinating  Committee  has  also 
been  established  to  promote  dialog  and  harmonization  among  the 
regional  workshops.  The  goal  of  the  workshops  is  to  define 
standards  profiles  that  will  ensure  interoperability  of  products 
from  different  vendors.  They  are  public  technical  fora  organized 
to  provide  timely  development  of  implementation  agreements 
and  testing  details  based  on  international  standards.  As  indicated 
in  Section  16.1.3,  the  Stable  Implementation  Agreements  [Ref. 

NIST  1991;  NIST  1993a]  from  the  OIW  form  the  basis  of  US 
GOSIP.  A  companion  document.  Continuing  Agreements  [Ref. 

NIST  1990c],  provides  the  basis  for  enhancements  and  future 
revisions  to  US  GOSIP. 

While  the  current  OIW  represents  a  successful  model  for  (winging  developers  together  to 
identify  the  additional  specificity  and  precision  required  to  ensure  product  interoperability,  the 
workshop  process  may  need  to  change  to: 

•  Include  users  in  an  active  and  visible  role  of  stating  requirements  and  priorities 

•  Broaden  the  base  of  technology  providers  participating  in  workshop  activities 

•  More  closely  align  and  synchronize  assignments,  responsibilities,  processes  and  work 
priorities,  and  outputs  with  other  regional  workshops,  user  groups,  and  vendor 
consortia 

•  Provide  a  way  for  bridging  specification  gaps  with  other  specifications  where 
appropriate  de  jure  standards  do  not  exist 

•  Adopt  a  top-down  versus  bottom-up  approach  that  reflects  a  market-driven  instead  of 
technology-driven  perspective. 

At  its  December  1991  meeting,  the  OIW  adopted,  by  unanimous  vote,  a  recommendation 
containing  the  following  points  [Ref.  Hovey  1992]: 

•  Revise  the  charter  of  the  OIW  to  explicitly  state  that  technical  subjects  going  beyond 
OSI  and  into  the  realm  of  OSEs  can  be  addressed  under  the  auspices  of  the  OIW. 

•  Revise  the  procedures  of  the  OIW  to  permit  the  workshop's  special  interest  groups  to 
propose  the  use  of  "public  domain  specifications." 

Section  13.1.2.5  describes  the  work  of  the  OIW  Technical  Committee  on  OSE  (TC-OSE). 
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The  IEEE  Profile  Steering  Committee,  formed  in  April  1991,  has  several  purposes.  It 
generates,  maintains,  and  interprets  profile  rules,  provides  guidance  to  profile  working  groups, 
and  provides  mechanisms  for  profile  harmonization.  Moreover,  it  effects  liaison  to  related  US 
profile  activities,  encourages  relationships  with  profile-generating  user  groups,  and  effects  liaison 
through  appropriate  channels  to  international  activities.  [Ref.  Martin  1992a] 

16.1.2  International  Standardized  Profiles  (ISPs) 

This  section  begins  by  describing  the  work  of  the  Special  Group  on  Functional 
Standardization  (SGFS)  of  ISO/I  EC  JTC1.  It  then  addresses  terminology,  taxonomy,  and  issues 
(Section  16.1.2.2).  This  is  followed  by  separate  sections  on  application  profiles 
(Section  16.1.2.3),  interchange  format  and  representation  profiles  (Section  16.1.2.4),  transport 
profiles  (Section  16.1.2.5),  and  relay  profiles  (Section  16.1.2.6).  The  section  ends  with  a 
description  of  the  taxonomy  of  OSE  profiles  (Section  16.1.2.7). 

16.1.2.1  Functional  Standardization  in  ISO/IEC 

ISO/IEC  JTC1  has  set  up  a  Special  Group  on  Functional  Standardization  (SGFS)  to 
develop  standards  for  international  standardized  profiles  (ISPs).  An  ISP  is  somewhat  more 
general  than  the  common  use  of  the  term  "profile"  in  that  a  profile  is  a  stack  of  protocols  to  be  used 
in  combination,  whereas  an  ISP  is  a  document  in  which  one  or  more  profiles  are  published.  The 
procedures  adopted  for  specifying  ISPs  are  unique  because  international  harmonization  is  intended 
to  be  achieved  before  candidate  ISPs  are  submitted  to  ISO.  Proposals  for  ISPs  are  expected  to  be 
accepted  by  the  international  regional  workshops  EWOS,77  OIW,  and  the  AOW  before  becoming 
proposed  draft  ISPs  (DISPs).  SGFS  has  approved  a  large  number  of  ISPs,  and  many  others  are 
being  discussed  in  the  regional  workshops. 

The  SGFS  meets  in  plenary  session  in  June  of  each  year,  1991-1995.  [Ref.  SGFS  N  242 
1991  ]  The  scope  of  the  work  of  the  SGFS  is  the  following  [Ref.  SGFS  N  293  1991]: 

•  Definition  of  functional  standardization  and  functional  standard 

•  Development  of  a  catalogue  of  functional  standards  with  appropriate  classification 

•  Definition  of  a  methodology  for  achieving  functional  standardization 

•  Development  of  a  set  of  operating  procedures  and  assessment  of  resources 

•  Execution  of  the  review  of  proposed  draft  functional  standards 

•  Consideration  of  functional  standards  requirements  on  conformance  and  maintenance 

•  Development  of  expeditious  publication  procedures. 

A  Directory  of  ISPs  and  Profiles  Contained  Therein  is  now  SGFS  Standing  Document 
SD-4  and  accompanies  TR  10000  to  provide  additional  information  about  ISPs  and  profiles. 
[SGFS  N  100,  February  1992]  It  is  currently  in  its  fourth  revision  and  includes: 

•  Status  information  about  each  profile  identified  in  TR  10000 

•  Summaries  of  existing  or  proposed  profiles 

•  Information  about  the  possible  joint  use  of  A/B  profiles. 

16.1.2.2  Functional  Standardization  Terminology,  Taxonomy,  and  Issues 

Terminology.  Table  44  provides  the  definitions  of  key  terms  for  functional 

standardization  drawn  from  WDTR  10000-3. 

77  A  proposed  FWOS  taxonomy  for  profiles  for  open  systems  environments  is  given  in  Section  15.1.3.8. 
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Table  44.  Terminology  lor  International  Standardized  Profllea 

Application  EnvEonmartf  (AE)  Profit*  (AIsP)— an  OSE  profile  that  apeeifiM  a  conpGto  and  coherent  subset  of 
the  Open  System  Environment. 

Application  platfomv— a  set  of  resources  on  wMch  an  appfication  will  run. 

Application  Program  Interface  (API)— the  interface  between  the  application  software  and  the  application 
platform,  across  which  services  are  provided. 

Component  profile — An  AE  profile  that  specifies  a  unit  of  functionality  in  terms  of  the  interfaces  that  it  supports 
and  the  interfaces  that  it  usee,  end  the  relationships  between  these  interfaces. 

Environment  (of  an  information  system)— that  part  of  the  real  world  containing  the  users  that  exchange 
messages  with  the  information  system. 

Interface  profite— an  OSE  profle  defining  one  interface  of  the  OSE 

International  Standardized  Profle  (ISP) — an  internet  ionaBy  agreed -to,  harmonized  document  that  identifies  a 
standard  or  group  of  standards,  togsther  with  options  and  parameters,  necessary  to  accomplish  a  function 
or  set  of  functions. 

Interoperabiity — the  abWty  of  two  or  more  systems  to  exchange  information  and  to  mutualy  use  the  information 
that  has  been  exchanged. 

Open  System  Environment  (OSE)— The  comprehensive  set  of  interfaces,  services,  and  supporting  formats  for 
interoperability  anchor  for  portability  of  applications,  data  or  people,  as  specified  by  information  technology 
standards  and  profiles. 

Portability  (software)— the  ease  with  which  software  can  be  transferred  from  one  information  processing  system 
to  another. 

Profile  (for  ISO  standardization)— A  set  of  one  or  more  base  standarde,  and,  where  applicable,  the  identification 
of  chosen  classes,  subset,  options,  and  parameters  of  those  base  standards,  necessary  for 
accomplishing  a  particular  function.  Note:  An  ISP  includes  the  specification  of  one  or  more  profles. 

Standardization — activity  of  establishing,  with  regard  to  actual  or  potential  problems,  provisions  for  common  and 
repeated  use,  aimed  at  the  achievement  of  the  optimum  degree  of  order  in  a  given  context. 

Unit  of  functionary  (UOF) — a  separately  implementabie  element  of  an  OSE  system. 


Taxonomy  Framework.  The  main  work  of  the  SGFS  is  the  development  of  a 
framework  (TR  10000-1),  taxonomy  for  ISPs  (TR  10000-2),  and  principles  and  taxonomy  for 
OSE  profiles  (WDTR  10000-3)  that  gives  priority  to  profiles  for  OSI  but  recognizes  that  the  profile 
principles  may  also  apply  to  other  technical  areas.  This  taxonomy  contains  a  classification  and 
identification  scheme  for  candidate  profiles,  is  being  adopted  by  TSGCE  SG9,  and  will  be  used  in 
forthcoming  editions  of  the  NATO  OSI  Profile  (NOSIP)™  TR  10000  identifies  profiles 
(specification  for  how  to  accomplish  a  function)  and  ISPs  (harmonized  documents).  TR  10000 
allows  an  ISP  to  contain  one  or  more  profiles  by  permitting  more  than  one  part,  each  of  which  can 
contain  a  profile.  It  is  expected  that  an  ISP  may  contain  5  to  10  profiles.  Profiles  may  only  be 
submitted  to  the  SGFS  by  one  of  the  three  regional  workshops  (OIW,  EWOS,  and  Asia  Oceania 
Workshop). 


Edition  2  of  TR  10000-1  remains  the  agreed  text,  although  Edition  3  is  in  WD  status. 
TR  10000-2  is  in  Edition  3.  The  December  1993  draft  of  WDTR  10000-2  [SGFS  N  1083]  has 
been  forwarded  by  SGFS  to  JTC1  for  DTR  balloting  [SGFS  N  1099  1993].  WDTR  10000-3  is  in 
its  first  version  and  there  are  several  key  issues  to  be  resolved  [Ref.  JTFS  92-468  1992];  these  are 
the  following; 

•  Coordination  with  other  groups  doing  OSE  work  is  needed. 

•  Hie  relationship  between  TR  10000-1  and  TR  10000-3  is  still  evolving. 

•  The  relationship  between  OSE,  Application  Environment  Profiles,  and  OSI  Profiles  is 
still  not  clear. 

•  There  is  no  clear  understanding  of  Functional  Profiles  outside  of  OSL 


78  SGFS  401,  currently  in  PDTR  status,  documents  the  taxonomy  update,  ISP  approval,  and  maintenance  proceu. 
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SGFS  is  now  developing  procedures  to  cover  other  TCs  and  the  OSE.  For  example,  when 
more  that  one  TC  is  involved,  extra  requirements  apply  such  as  the  generation  of  a  multi-TC  ISP 
memorandum  of  agreement  (MOA)  document  [Ref.  SC21  N  7360  1992}  In  December  1993, 
the  SGFS  agreed  to  begin  to  resolve  national  body  comments  on  WDTR  10000*1  and  10000*3  by 
specifying  an  open  system  (application  platform)  that  should  support  application  portability  but  not 
exchangeability  of  physical  or  software  components.  It  was  also  agreed  that  interoperability  was  to 
be  taken  as  a  fundamental  requirement,  and  so  the  emphasis  on  application  portability  should  be 
understood  to  include  both  portability  and  interoperability.  [Ref.  SGFS  N  1099  1993] 

In  December  1993,  SGFS  agreed  to  allow  profiles  to  reference  a  publicly  available 
specification  (PAS)  as  long  as  the  references  are  informative  (not  normative)  and  as  long  as  the 
PAS  fills  an  identified  gap  in  the  profile  for  which  there  is  no  base  standard.  The  long-term 
solution  to  this  problem  is  development  of  OSE  profiles.  [Ref.  SGFS  N  1090 1993] 

Issues.  SGFS  Standing  Document  SD*7,  Issues  List  for  Future  Development  oflSO/IEC 
Tfl  IOOOO,  September  1993.  lists  the  following  current  open  issues  [Ref.  SGFS  SD-7  1993]: 

•  Protocol  profile  testing  methodology 

•  Conformance 

•  PICS  Proforma  instructions  and  Annex  C  of  TR  10000- 1 

•  Profile  qualifiers  and  orthogonal  functions 

•  Terminology:  choice  between  AEP  and  OSE 

•  Taxonomy 

•  Conformance  testing  of  OSE 

•  Profile  versions  and  ISP  revisions 

•  Cultural  elements  in  ISP  and  its  taxonomies 

•  Relationship  between  OSI  and  OSE 

•  Scope  of  OSE  profiles 

•  Call  for  studies 

•  Relationship  of  TR  10000  with  ODP 

•  Taxonomy,  profile  identifiers,  and  profiles 

•  Expansion  of  the  scope  of  TR  10000-3  to  include  system  software  portability. 

Related  Activities.  SGFS  has  accepted  the  responsibility  for  profile  test  specifications, 

which  will  be  produced  on  the  same  basis  as  the  profile  definitions  produced  by  the  SGFS 
[Ref.  SC6  N  6976  1991]: 

•  They  will  be  published  as  ISPs  or  ISP  parts,  related  to  the  ISPs  for  the  profiles  to 
which  the  tests  relate. 

•  Criteria  for  inclusion  of  references  to  the  base  standards  for  relevant  abstract  test  suites 
will  be  the  same  as  those  for  references  to  PICS  proformas. 

•  Methods  of  generating  and  balloting  ISPs  will  be  the  same  as  for  profiles. 

The  Regional  Workshops  Coordinating  Committee  (RWS-CC)  of  ISO  JTC1  has  noted  a 
number  of  haimonization  efforts:  conveyance  of  ODA  over  MHS(84);  FT AM  document  types 
from  CGM.  COBOL,  ODA,  and  EDI;  a  Document  Application  Profile  (DAP)  for  raster  graphics  in 
ODA;  general  upper  layer  agreements;  character  set  repertoires  and  their  encoding;  and  an 
international  registry  (IR)  or  library  (IM1L).  [Ref.  SGFS  N  282  1991] 
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Table  45  shows  the  overall  organization  and  labels  (taxonomy)  used  to  identify  and 
distinguish  ISPs.  It  shows  the  distinctions  created  by  the  choice  of  connection-oriented  (CO)  or 
connectionless  (CL)  modes.  There  are  four  classes  of  ISPs  in  the  taxonomy  of  TR  10000: 
application  profiles  (AXXnn  for  those  requiring  the  COTS  and  BXXnn  for  those  requiring  CLTS); 
interchange  format  and  presentation  profiles  (FXXnri);  transport  profiles  (TXnnnn  and  UXnnnn 
for  CO  and  CL  profiles,  respectively);  and  relay  profiles  ( r"'p,q ). 

Tabl*  45.  OvarvUw  of  Taxonomy  for  International  Standardized  Prof! tea 


A  Application  profits*  using  CO -mod*  transport  service  (TS) 

B  Application  profiles  using  CL-mode  TS 
F  Interchange  format  and  representation  profiles 
T  Transport  profiles  providing  CO-mode  TS 

•  TA  CO-TS  over  CL  network  service  (CLNS)  using  Transport  Protocol  (TP)  Class  4  as  defined 

in  ISO  8073/AD  2 

•  TB  CO-TS  over  CO  network  service  (CONS)  with  provision  of  TP  Classes  0.2,  and  4 

•  TC  CO-TS  over  CONS  with  provision  of  TP  Classes  0  and  2 

•  ID  CO-TS  over  CONS  with  provision  or  TP  Class  0 

•  TE  CO-TS  over  CONS  with  provision  of  TP  Class  2 

U  Transport  profiles  providing  CL-mode  transport  service  (TS) 

•  UA  CL-TS  over  CLNS 

•  UB  CL-TS  over  CONS 

R  Relay  profiles  between  T-  or  U-profiles  _ 


16.1.2.3  Application  Profiles 

These  profiles  are  coded  by  application  supported  and  transport  mode  required  (three 
letters,  where  the  first  letter  is  "A"  if  requiring  COTS  and  "B"  if  requiring  CLTS— no  BXX  tut 
profiles  have  yet  been  identified),  service  type  (first  digit),  and  functional  association  (second 
digit).  The  applications  are : 

•  Directory:  ADIn  (e.g..  Directory  access  is  ADI1;  Directory  system  is  ADI2; 
distributed  operations  in  ADO;  Directory  use  of  strong  authentication  is  ADI4) 

•  FTAM:  AFTnn  (e.g.,  file  transfer  service  is  AFT1;  file  access  service  is  AFT2;  file 
management  service  is  AFT3;  filestore  management  service  is  AFT4) 

•  Library,  Documentation:  ALDnn  (e.g.,  search  and  retrieve  is  ALD1;  interlibrary  loan 
is  ALD2) 

•  MHS:  AMHnn  (e.g.,  common  messaging  is  AMH1;  interpersonal  messaging  is 
AMH2;  EDI  messaging  is  AMH4) 

•  MMS:  AMMrw  (e.g.,  general  applications  is  AMM1;  robot  controller  applications  is 
AMM2;  numerical  controller  applications  is  AMM3;  programmable  logic  controller 
applications  is  AMM4;  process  industries  applications  is  AMM5) 

•  OSI  Management:  AOMnn  (e.g.,  management  communications  is  AOM1; 
management  functions  is  AOM2) 

•  RDA:  ARD 

•  TP:  ATPnn  (e.g.,  application-supported  transactions  is  ATP1;  provider-supported 
unchained  transactions  is  ATP2;  provider-supported  chained  transactions  is  ATP3) 

•  VT:  AVTnn  [e.g.,  Basic  Class  (A-mode)  is  AVT1 ;  Basic  Class  (S-mode)  is  ALD2]. 

Regional  workshops  (e.g.,  EWOS,  OI W)  have  defined  and  ISO/IEC  has  adopted  ISPs  for 

a  number  of  application  profiles.  These  include  the  following  multi-part  standards,  which  are 
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listed  in  their  entirety  (each  part  and  amendments)  in  Section  I.H  of  Appendix  D  and  Section  I  of 
Appendix  E: 

•  ISO/IEC  ISP  10607,  ISPs  AFT  nn  •  File  Transfer,  Access,  and  Management 
(Parts  1-6),  December  1991 

•  ISO/IEC  ISP  10610,  ISPs  FOD  nn,  Document  Structure 

•  DISP  1061  IJSPsAMHln  -  Message  Handling  Systems  (Parts  1-5),  April  1992 

•  DISP  10615,  ISPs  ADI  nn  -  OSI  Directory  (Parts  1-7),  January  1993 

•  DISP  10616,  ISP  FDI  11  -  Directory  Data  Definitions  -  Common  Directory  Use, 

September  1993 

•  ISO/IEC  ISP  11181,  ISP  FOD26  -  Enhanced  Document  Structure  -  Character,  Raster 
Graphics  and  Geometric  Graphics  Content  Architecture,  April  1992 

•  ISO/IEC  ISP  11182,  ISP  FOD36  -  Extended  Document  Structure  -  Character,  Raster 
Graphics  and  Geometric  Graphics  Content  Architecture,  April  1992 

•  pDISP  11184,  ISPs  FVT  Inn  -  Virtual  Terminal  Basic  Class  -  Register  of  VTE 
Profiles  (Parts  1-7),  1993 

•  DISP  11185,  ISPs  FVT  2nn  -  Virtual  Terminal  Basic  Class  -  Register  of  VT  Control 
Objects  (Parts  1-17),  August  1993 

•  pDISP  11186,  ISPs  FVT  3nn  -  Virtual  Terminal  Basic  Class  -  Register  of  Assignment 
Type  Definitions,  1993 

•  DISP  11187,  ISPs  FVT  3nn  -  Virtual  Terminal  Basic  Class  -  Application  Profiles 
(Parts  1-10),  1993 

•  pDISP  11188,  ISPs  -  Common  Upper  Layer  Requirements  (Parts  1-3),  July  1993 

•  DISP  11189,  ISP  FDI2  -  MHS  Use  of  Directory,  September  1993 

•  DISP  1 1 190,  ISP  FDI3  -  FTAM  Use  of  Directory,  September  1993 

•  DISP  12061,  ISPs  ATP  nn  -  OSI  Distributed  Transaction  Processing  (Parts  1-11), 
July  1993. 

Application  profiles  for  OSI  management  adopted  by  ISO/IEC  are  the  following: 

•  ISO/IEC  ISP  11183,  ISPs  AOM  In  -  OSI  Management  -  Management 
Communications  Protocols  (Parts  1-3),  December  1992 

•  DISP  12059,  ISPs  -  Management  Functions  -  Common  Information  for  Management 
Functions  (Parts  0-6),  1992 

•  DISP  12060,  ISPs  AOMnnn  -  OSI  Management  -  Management  Functions  (Parts  1-5), 
1992. 

16.1.2.4  Interchange  Format  and  Representation  Profiles 

ISPs  for  interchange  formats  and  representations  are  coded  by  information  type  (three 
letters),  document  structure  (first  digit),  and  architecture  (second  digit).  The  information  types  are 
(the  last  two  have  no  two-digit  extensions): 

•  Computer  graphics:  FCGnn 

•  Directory  data  definitions:  FDInn  (e.g.,  common  Directory  use  is  FOD1;  MHS  use  of 
Directory  is  FDI2;  FTAM  use  of  Directory  is  FDD) 

•  Office  document:  FODnnn  (e.g.,  document  processing  applications  is  FODO;  image 
applications  is  FOD1) 

•  SGML  document:  FSGnn 

•  Virtual  terminal  control  objects:  FVTnn. 
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Section  7.1.1  lists  the  office  document  profiles  under  development  Section  5.2.3  lists  the 
VT  profiles  under  development  Section  9.1 1.7.5  lists  the  Directory  profiles  under  development 

16.1.2.5  Transport  Profiles 

Transport  profiles  (Figure  18)  are  coded  by  transport  mode  (first  letter  ”T"  for  COTS  and 
MU”  for  CLTS),  transport  group  (second  letter),  subnetwork  type  (first  digit),  access  method 
(second  digit),  circuit  type  (third  digit),  and  service  type  (fourth  digit).  The  transport  groups  are 
CLNS  (TA  or  UA),  TP  0/2/4  over  CONS  (TB  or  UB),  TP  0/2  over  CONS  (TQ,  TPO  over  CONS 
(7Z>),  and  TP2  over  CONS  (TE).  The  subnetwork  types  are  PSDN  (M1 "),  digital  data  circuit  ("2"), 
analog  telephone  circuit  ("3"),  ISDN  ("4"),  and  LAN  ("5").  The  access  methods  differ  for  circuits 
and  LANs: 

•  Circuit  access:  permanent  ("1"),  switched  ("2"),  and  packet  mode  ("3") 

•  LAN  access:  CSMA/CD  ("1"),  token  bus  ("2"),  token  ring  ("3").  and  FDDI  ("4"). 


Figure  18.  Taxonomy  for  International  Standard  Transport  P,  'filas 
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Transport  profiles  defined  by  regional  workshops  and  adopted  by  ISO/IEC  include  the 
following  multi-part  standards,  which  are  listed  in  their  entirety  (each  part  and  amendment)  in 
Section  I.H  of  Appendix  D  and  Section  I  of  Appendix  E: 

•  ISO/IEC  ISP  10608,  ISPs  TA  nnnn  -  Connection-mode  Transport  Service  over 
Connectionless-mode  Network  Service  (Parts  1-14),  1992 

•  ISO/IEC  ISP  10609,  ISPs  TB,  TC,  TD,  and  TE  -  Connection-mode  Transport  Service 
over  Connection-mode  Network  Service  (Parts  1-38),  1992. 

16.1.2.6  Relay  Profiles 

These  profiles  are  coded  by  relay  type: 

•  CLNS:  RAp.q 

•  CONS:  RBp.q 

•  X.25:  RCp.q 

•  MAC  using  transport  bridging:  RDp.q 

•  MAC  using  source  routing:  REp.q 

•  CLNS  to  CONS:  RZp.q. 

The  four-digit  numbers  p  and  q  each  use  the  four-digit  numerical  classification  of  the 
transport  profiles.  They  thereby  identify  the  subnetwork  types  between  which  the  relay  occurs. 

Relay  profiles  defined  by  regional  workshops  and  adopted  by  ISO/IEC  include  the 
following  multi-part  standards,  which  are  listed  in  their  entirety  (each  part  and  amendment)  in 
Section  I.H  of  Appendix  D  and  Section  I  of  Appendix  E: 

•  DISP  10612,  ISPs  RD  nn.nn  (Parts  1-9),  1993 

•  DISP  10613,  ISPs  RA  nn.nn  -  Relaying  the  Connectionless-mode  Network  Service 
(Parts  1-9),  1993 

•  DISP  10614,  ISPs  RC  nrunn  -  Relaying  X.25  PLP  (Parts  1-6),  1993. 

16.1.2.7  Open  System  Environment  Profiles 

Table  46  identifies  die  taxonomy  of  OSE  profiles  included  in  the  current  draft  of 
WTR  10000-2.4  and  WDTR  10000-3.  Note  that  there  are  two  classes  of  these  profiles: 
application  environment  profiles  and  interface  profiles. 

16.1.3  National  and  Multinational  GOSIPs 

16.1.3.1  UK  and  US  GOSIP 

This  section  discusses  UK  GOSIP  and  US  GOSIP,  illustrated  side  by  side  in  Figures  19 
and  20.  Documentation  for  UK  GOSIP  was  originally  issued  in  March  1988  for  mandatory  use  in 
1990.  It  is  now  in  Version  4.  {Ref.  OSN  1991  i,  19]  Figure  19  shows  the  standards 
recommended  for  UK  GOSIP.  Documents  for  Version  4  of  UK  GOSIP,  UK  Government  OSI 
Profile,  are  [Ref.  CCTA  1992a;  CCTA  1992b]: 

•  Volume  I,  Introduction 

•  Volume  II,  Specification 

•  Volume  III,  Procurement  Handbook. 

Previously,  UK  GOSIP  was  completely  revised  and  updated  on  an  annual  basis.  Now  the  life 
span  of  the  new  GOSIP  4  document  sets  is  expected  to  be  2-3  years,  which  will  allow  periodic 
updates  to  be  added  into  the  new  ring-binder  format.  [Ref.  OSN  1991m] 
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Tabte  46.  Example  Taxonomy  for  Application  Environment  Proflies 


|P~65E  ffgfigr 

AEP 

AEP  Profit** 

PC 

Component  Profiles  | 

PS 

System  Profiles 

PSB 

Base  Environment  Profles 

PSB1 

Generic  Base  Environment 

PSB2 

...  (to  be  extended  if  necessary) 

PSE 

Generic  Environment  Profiles 

PSE1 

Workstation  Environments 

PSE10  Terminal  Environment 

PSE11  Personal  Workstation  Environment 

PSE12  Professional  Workstation  Environment 

PSE2 

UtHNy  Server  Environments 

PSE20  Electronic  Meesage  Senring  Environment 

PSE21  Directory  Serving  Environment 

PSE22  Access  Control  Senring  Environment 

PSE3 

Information  Server  Environments 

PSE30  DBMS  Serving  Environment 

PSE31  Document  Serving  Environment 

PSE4 

Transaction  Processing  Environments 

PSE40  Simple  TP  Environment 

PSE41  Enhanced  TP  Environment 

PSE5 

Real-Time  Environments 

PSE50  Real-Time  Environment,  seconds 

PSE51  Real-Time  Environment,  mWeeconds 

PSE6 

Supercomputing  Environments 

IP 

Interface  Profiles 

HO 

Human-Computer  Interface 

CMI 

Communication  Interface 

ISI 

Information  Interface 

API 

Application  Program  Interface 

Rather  than  repeat  UK  GOSIP,  Canada  has  prepared  Canadian  Open  Systems  Applications 
Criteria  (COSAC)  as  a  Government  strategy  toward  open  systems.  The  strategy  is  analogous  to 
UK  GOSIP  and  fully  subscribes  to  ISO  conventions.  The  mandate  of  the  Department  of  National 
Defence  in  Canada  is  to  follow  COSAC  (i.e.,  UK  GOSIP)  where  defined  and  otherwise  to  revert 
to  ISO  open  systems  specifications.  Canada  does  not  plan  to  develop  a  national,  made-in-Canada 
open  system  architecture.  [Ref.  Beggs  1992] 

Figure  20  shows  the  standards  and  options  recommended  for  US  GOSIP,  Version  2.0. 
[Ref.  GOSIP  1990]  These  are  based  on  the  March  1990  Stable  Implementation  Agreements  far 
Open  Systems  Interconnection  Protocols,  Version  3,  Edition  1,  of  the  OIW  [Ref.  NIST  1990b] 
Version  1.0  was  issued  as  FIPS  146  on  August  1989.  Version  2.0  was  issued  as  FIPS  146*1  on 
October  1990.  Use  of  FIPS  146  was  mandatory  August  1990,  and  FIPS  146-1  became  mandatory 
on  October  1991. 

Whereas  in  Version  1.0  of  US  GOSIP  only  the  CL-mode  network  layer  protocols  were 
recommended  for  packet  switched  wide  area  networks  (WANs),  Version  2.0  makes  CO-mode 
network  service  optional.  This,  and  the  addition  of  the  Network  Service  Access  Point  (NSAP) 
address  structure,  will  align  the  standard  with  those  currently  being  addressed  by  ISO. 
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SERVICES: 
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LAYER  7 
Application 


T 


LAYER 6 
Presentation 

1 

LAyEr 5 

Session 


LAYER  4 
Transport 

± 
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LAYER 3 
Network 

1 

T 

LAYER 2 
Data  Link 

1 

T 

LAYER  1 
Physical 

1 

TRANSPORT 

SERVICE: 


MittBQfl 

Handing 
Service  (MHS) 

X. 400- 1984 
Series 

Virtual 
Terminal 
ISO  9040 
ISO  9041 

Fite  Transfer,  Access,  and  Management  (FT AM) 

DIS  8571 

1 

_ l _ 

Association  Control  Service  Elements  (ACSEs) 

DIS  8649.  DIS  8650 

i 

DIS  8823 

Abstract  Syntax  Notation,  ASN.1:  DIS  8824,  DIS  8825.2 

ISO  8327 


Transport  Class  0 
ISO  8072,  8073 

Transport  Classes  2  and  4 

ISO  8072,8073 

Connect  ion -Oriented  Network 
Service  (CONS) 

X25PLP 

ISO  8208,  ISO  8878 

Connectionless  Network  Service  (CLNS) 

ISO  8348, 8473 

High-Level  Data  Link  Control 
(X25HDLC) 

Link  Access  Procedure  B  (LAP  B) 

ISO  7776 

Logical  Link  Control  (LLC)  DIS  8802-2 

CSMA/CO 

(Ethernet) 

DIS  8802-3 

TOKEN 

RMG 

DIS  8802-5 

V.24 

V.35 

X21 

WOE  ANEA  NETWORK  MAN: 
PACKET  SWITCHED  DUS) 


TOKEN  NNO 


Figure  19.  Stacks  of  Standards  Recommended  for  UK  60SIP 
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(ISO  8660) 
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Connection-Oriented  Presentation  Protocol 
(ISO  8823) 


Connection-Oriented  Session  Protocol  (ISO  8327) 


Connection-Orisntod  Transport  Protocol 
Class  4  (ISO  8073) 
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Services 

Digital 


(ISDN) 
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Layer  Protocol 
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Connectionless 
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(ISO  8473) 

ES4S 
(ISO  0542) 
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HDLCLAPB 
(ISO  7776) 

V.35 

RS-232 

RS-530 
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|  Logical  Link  Control  (ISO  8802-2)  j 

CSMA/CD 
(ISO  8802-3) 
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Figure  20.  Stacks  of  Standards  Recommended  for  US  GOSIP  (Version  2.0) 
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Versions  of  US  GOSIP  will  continue  to  be  based  on  the  stable  implementation  agreements 
reached  in  the  regional  OSI  Implementor's  Workshop.  Working  agreements  from  the  OIW  that 
have  not  reached  final  form  are  found  in  the  Working  Implementation  Agreements  for  Open 
Systems  Interconnection  Protocols:  Continuing  Agreements.  These  agreements  provide  the  basis 
for  future  projections  of  US  GOSIP. 

In  addition  to  recognizing,  including,  and  resolving  Version  1.0  errata.  Version  2.0  of  US 
GOSIP  |Ref.  GOSIP  1990],  also  includes  the  following  protocols:  VT  (forms  profiles  and 
TELNET),  ODA/ODIF,  ISDN,  connection-oriented  network  service,  connectionless  transport,  and 
end-system  to  intermediate  system  (ES-IS)  network  layer  protocols.  These  protocols  would  be 
added  in  Version  3.0,  which  is  planned  for  1995:  Directory  services  (ITU-TS  X.500),  VT  (page, 
scroll,  and  forms),  1988  ITU-TS  extensions  to  MHS,  FTAM  extensions,  FDDI,  optional 
Transport  Class  2,  Computer  Graphics  Metafile,  MMS,  network  management,  optional  security 
enhancements,  SGML,  EDI,  and  intra-domain  routing  protocols.  Version  4.0,  planned  for  1997, 
will  include  transaction  processing  (TP),  remote  database  access  (RDA),  additional  network 
management,  additional  optional  security,  and  inter-domain  routing  protocols.  [Ref. 
OSN  1991e,  p.4] 

A  detailed  description  of  the  plans,  based  on  US  GOSIP,  to  introduce  OSI  protocols  into 
the  US  DoD  is  provided  in  The  Department  of  Defense  Open  Systems  Interconnection  (OSI) 
Implementation  Strategy.  [Ref.  MITRE  1988]  The  baseline  for  US  tactical  implementation  of  OSI 
standards  and  protocols  will  be  based  on  the  work  of  TSGCE  SG9,  the  NTIS  Transition  Strategy, 
and  associated  STANAGs.  Tactical  networks  may  use  GOSIP-specified  lower-level  protocols 
until  NTIS  protocols  are  developed  and  commercially  available.  When  the  NATO  standards  are 
complete,  approved,  and  available,  those  required  for  DoD  use  will  be  introduced  as  GOSIP 
Advanced  (post- 1989)  Requirements.  [Ref.  MITRE  1988] 

While  some  major  vendors  such  as  IBM  are  offering  (or  about  to  offer )  OSI  for  much  or 
all  of  their  product  line,  they  are  typically  offering  TCP/IP  as  well.  The  August  1990  US  GOSIP 
mandate  seems  to  have  influenced  the  schedule  for  many  of  the  OSI  implementors,  so  a  number  of 
first  generation  OSI  products  either  are  just  appearing  or  expected  shortly.  Activity  in  the  TCP/IP 
product  lines  is  undiminished.  [Ref.  PSSG  1991] 

NIST  is  publishing  a  series  of  US  GOSIP  evaluation  guidelines  that  are  now  available  for 
electronic  mail  and  transfer.  These  guidelines  explain  how  implementations  can  differ,  and  they 
assist  Federal  agencies  and  other  users  in  determining  which  among  several  implementations  best 
suits  their  needs.  [Ref.  OSN  199  le,  5] 

Since  Version  3.0  of  US  GOSIP  will  be  introducing  standardized  network  management,  an 
important  area  where  a  lot  of  standards  work  remains  to  be  done,  NIST  is  developing  a  number  of 
FIPS  concerning  network  management  They  will  be  published  in  stages,  one  each  year  for  the 
next  three  years,  and  will  describe  the  objects  that  have  to  be  managed  to  perform  network 
management  or  OSI  management  in  the  following  functional  areas: 

•  Phase  I:  802,  X.25,  ISDN,  FDDI,  modems,  multiplexes,  bridges,  and  physical  link 

•  Phase  II:  protocol  software,  routers,  terminal  services,  MTAs,  PBXs,  and  circuit 
switches 

•  Phase  III:  applications,  services,  operating  systems,  computer  networks,  and 
DBMSs. 
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The  staging  of  these  FIPS  reflects  user  priorities.  In  a  survey  of  Federal  agencies,  NIST 
found  that  the  most  important  area  is  management  for  local  area  networks  and  Layers  1  and  2  of  the 
OSI  Reference  Model.  Next  were  Layers  3-7  and  then  network  management  applying  to  operating 
systems,  applications,  and  services.  [Ref.  OSN  1991e,  7] 

16.1.3.2  NOSIP 

Subgroup  9  of  NATO’s  TSGCE  has  recently  released  Version  3  of  the  NATO  Open 
Systems  Interconnection  Profile  (NOSIP)  Strategy  [Ref.  NATO  1993].  This  document  identifies  a 
number  of  international  standards  as  base  standards  and  emerging  international  profiles  for  use  in 
NATO  systems.  Appendixes  D  and  E  identify  each  standard  listed  and  profile  included  in  the 
NOSIP  Strategy.  The  following  (draft)  STANAGs  are  under  development  as  military  profiles 
based  on  international  standards: 

•  STANAG  4406,  Military  Message  Handling  System,  Draft,  NATO  UNCLASSIFIED 
(cf.  ISO  10021, 10611) 

•  STANAG  4407,  System  Management,  Draft,  NATO  UNCLASSIFIED  (cf.  ISO 
10165-1, 10165-2, 10165-4, 10164, 11183, 12059, 12060) 

•  STANAG  4408,  Connection-mode  Transport  Service  over  Connectionless-mode 
Network  Service  (Parts  1-4) 

•  STANAG  4409,  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service  (Military)  (Parts  1-3) 

•  STANAG  4410,  Connectionless-mode  Transport  Service  over  Connectionless-mode 
Network  Service 

•  STANAG  4413,  Relaying  the  Connectionless-mode  Network  Service  (Parts  1-4). 

16.1.3.3  Multinational  GOSIP— IGOSS" 

The  Industry/Government  Open  Systems  Specification  (IGOSS)  [Ref.  IGOSS  1993]  is 
jointly  authored  by  the  US  Government,  the  Canadian  Government,  MAP  Users  Group,  TOP 
Users  Group,  and  the  Electric  Power  Research  Institute  (EPRI).  Each  of  these  five  major  user 
organizations  have  issued  their  own  procurement  profiles  to  coordinate  the  acquisition  and 
operation  of  computer  networking  products  and  services  based  on  OSI  standards.  In  the  future, 
these  organizations  intend  to  specify  OSI  profiles  (e.g.,  GOSIP)  primarily  by  reference  to  IGOSS 
in  future  editions  of  such  documents  as  the  following: 

•  Canadian  Open  System  Application  Criteria  (COSAC)  [to  be  issued  as  a  Treasury 
Board  Information  Technology  Standard  (TBITS)] 

•  MAP  specification 

•  TOP  specification  (see  Section  15. 1 .3.6) 

•  US  GOSIP  [to  be  issued  as  a  Federal  Information  Processing  Standard  (FIPS)] 

•  Utility  Communications  Architecture. 

IGOSS  defines  profiles  for  the  following: 

•  Message  Handling  Systems  (ITU-TS  1988  Recommendations) 

•  Electronic  Data  Interchange  (EDI)  User  Agent 

•  Hie  Transfer,  Access,  and  Management  (FT AM) 

•  Virtual  Terminal  Service,  Remote  Database  Access,  and  Transaction  Processing 

•  Directory  service 

79  The  material  for  this  section  it  excopied  from  [IGOSS  1993], 
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•  Manufacturing  Message  Specification  (MMS) 

•  X- Windows  over  OSI 

•  Information  retrieval 

•  Fiber  Distributed  Data  Interface  (FDDI) 

•  Frame  relay 

•  Point-to-Point  Protocol  (PPP) 

•  Intermediate  System  to  Intermediate  System  (IS-IS)  Routing  Protocol 

•  Inter-Domain  Routing  Protocol  (1DRP) 

•  Network  management  protocols 

•  Connectionless  Upper  Layer  services. 

The  primary  sources  for  IGOSS  are  ISPs  and  the  stable  implementation  agreements  from 
the  North  American  OIW.  Secondary  sources  (in  order  of  precedence)  are  international  standards 
and  recommendations  from  ISO  and  ITU-TS;  draft  international  standards;  IEEE  standards;  and 
working  implementation  agreements  from  the  OIW.  In  some  cases,  IGOSS  makes  reference  to 
tertiary  sources,  which  are  (in  order  of  precedence):  ANSI  standards;  Canadian  Standards 
Association  standards;  committee  draft  international  standards;  FTPSs;  CTBITS;  Internet  standards 
and  requests  for  comment  (RFCs);  and  military  standards. 

IGOSS  defines  application  subprofiles,  lower-layer  subprofiles,  and  subnetwork 
subproflies.  These  subproflles  are  combined  to  provide  product  specifications  for  procurement 
An  overview  of  these  subproflles  is  provided  in  Figure  21.  Application  subproflles  in  IGOSS  are 
summarized  in  Table  47  and  transport  and  relay  profiles  in  Table  48. 
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Figure  21.  IGOSS  Subprofikre 
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Table  47.  IGOSS  Application  Subprofilea 


SubproflU 


tandards  for  tha  Subprofila 


IJJI-I  mv.  llM.f 


ISO  8327  ISO  8823 


ISO  8327  I  (Nul) 


ISO  8327  ISO  8823 


S  X.410  (RTS) 


ISO  8327  I  ISO  8823  I  ISO  8650  (ACSE) 


ISO  8327  ISO  8823 


IKsES3RZjB= 


ISO  8650  (ACSE) 


Connectionless  I  ISO  9548  I  ISO  9576  IS0 10035  (ACS 


Source:  [IGOSS  1993] 


ITU-TS  X.40O.1984 


ISO  10026-3 


ISO  9506 


ISO  9596-1 


mil 
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Table  48.  IGOSS  Transport  and  Ralay  Subprofiles 


linuMiiEr]! 


er  1 


(Nul)  I  (Nul) 


Standards  for  tha  Subprofile 


or  3 


ISO  8348, 8348/ADl  (CLNS) 
ISO  8473  (CLNP) 

ISO  9542  (ES-IS  Routing 
Protocol) 


ISO  8072, 8072/ADI  (CLTS) 
ISO  8602  (CLTP) 


Id.  1.4  European  Procurement  Handbook  for  Open  Systems  (EPHOS) 
Decision  87/95  from  the  European  Community  (EC)  requires  the  specification  of  OSI 
standards  for  public  procurements.  A  document  is  being  developed  by  France,  Germany,  and  the 
United  Kingdom  to  provide  guidance  for  such  procurements.  The  document  is  called  the  European 
Procurement  Handbook  for  Open  Systems  (EPHOS)  and  is  based  on  base  profiles  of  the  UK 
GOSIP  specification.  Where  possible,  EPHOS  will  cite  European  standards  and  ISPs. 

In  early  1991,  EPHOS  achieved  two  significant  milestones.  The  Phase  I  draft  covering 
X.2S,  MHS,  and  FT  AM  now  reflects  member  nations'  formal  comments,  and  Phase  II  has 
progressed  to  the  point  of  agreement  on  further  coverage.  The  original  intention  to  publish 
procurement  guidance  on  MHS-88  has  been  undermined  by  slow  progress  on  the  European 
standards,  and  EPHOS  Phase  I  has  been  revised  to  focus  on  MHS-84  with  only  preliminary 
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guidance  on  specifying  MHS-88  added  functionality.  Phase  II  topics  will  include:  Phase  I 
maintenance,  FTAM,  MHS-88,  LAN,  cabling,  document  formats,  character  repertories.  Security, 
EDI,  directory  services,  VT,  LAN/WAN  interworking,  and  identification  of  areas  where  standards 
arc  inadequate  or  absent.  [Ref.  OSN  199 lg] 

16.1.5  International  Versions  of  GOSIP 

Initiatives  have  been  taken  to  develop  an  international  version  of  GOSIP.  The  initial 
meeting  in  October  1988  was  sponsored  by  the  United  Kingdom,  with  participation  from  France, 
Germany,  Canada,  Japan,  Sweden,  and  the  United  States. 

16.1.6  US  Military  Standardized  Profiles  for  Open  Systems 

The  US  DTMP  is  developing  a  number  of  Defense  Standardized  Profiles  (DSPs)  that  meet 
US  military  requirements  and  that  could  be  submitted  to  TSGCE  SG9  to  be  considered  as  potential 
NATO  Standardized  Profiles.  Table  49  shows  the  status  of  DTMP  profile  development  as  of 
January  1994.  These  are  listed  with  full  titles  along  with  other  national  military  standards  and 
profiles  in  Section  II.B  of  Appendix  H. 


TabU  40.  US  Defense  Standardized  Profile  Development 
3500-Series—-  Network/Relay  Profiles/Multi-Layer  — 

MIL-STD-1 745-1 3500,  Internet  Relay  Profile  for  DoD  Communications  -  Point-to-Point  Protocol  (PPP),  Working 
Draft.  Draft.  1993 

4500-Series— -Transport  Profilee/Multi-Layer 

MIL-STD-1 745-1 4500,  DSPs  -  Reliable  End  System  (ES)  Transport  for  DoD  Communications.  Draft.  1993 
(approved  by  DTMP  for  validation) 

MIL-STD-1 745-14501.  DSPs  -  Simplex  Transport  Profile  (in  SD-1  coordination80) 

MIL-STD-1 745-1 4502-01,  DSPs  -  Internet  Transport  Profile  for  DoD  Communications.  Part  1:  Transport  and 
Internet  Services.  Draft.  1993  (in  SD-1  coordination) 

MIL-STD-1 745-14502-02.  DSPs  -  Internet  Transport  Profile  for  DoD  Communications.  Part  2:  Point-to-Point 
Links,  Draft.  1993  (in  SD-1  coordination) 

MIL-STD-1 745-14502-03,  DSPs  -  Internet  Transport  Profile  for  DoD  Communications,  Part  3:  Wide  Area  Network 
Access.  Draft.  1993  (in  SD-1  coordination) 

MIL-STD-1 745-1 4502-04.  DSPs  -  Internet  Transport  Profile  for  DoD  Communications,  Part  4:  Local  Area  Network 
(LAN)  Media  Independent  Requirements,  Draft,  1993  (in  SD-1  coorcfination) 

MIL-STD-1 745-1 4502-05.  OSPs  -  Internet  Transport  Profile  for  DoD  Communications.  Part  5:  Carrier-Sense 
Multiple  Access  with  Collision  Detection  (CSMA/CD)  Local  Area  Network  (LAN)  Media  Dependent 
Requirements.  Draft,  1993  (in  SD-1  coordination) 

MIL-STD-1 745-1 4502-06.  DSPs  -  Internet  Transport  Profile  for  DoD  Communications,  Part  6:  Combat  Net  Radio, 
Draft,  1993  (in  SD-1  coordination) 

MIL-STD-1 745-44500.  Tactical  Communications  2  (TAC02),  Draft,  1993  (sent  to  Navy  publications) 
7500-Series— Application  Profiles/Multi-Layer 

MIL-STD-1 745-1 7501  -01,  DSPs  AMH  In  (D  )•  Message  Handling  System  (MHS)  Common  Messaging,  Part  1: 

MHS  Service  Support,  Draft,  1993  (sent  to  Navy  publications) 

MIL-STD-1 745-1 7501  -02,  DSPs  AMH  In  (D  )-  Message  Handling  System  (MHS)  Common  Messaging.  Part  2: 
Specification  of  ROSE,  RTSE,  ACSE,  Presentation  and  Session  Protocols  for  use  by  DoD  MHS.  Draft. 
1993  (sent  to  Navy  publications) 


80  Standardization  Directory  (SD-1)  coordination  is  conducted  to  provide  a  baseline  (incorporating  comments  from 
SD- 1  coordination)  for  formal  validation  prior  to  final  approval  and  publication. 
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Table  49.  (Cont’d) 


MIL-STD-1 745-1 7501  -03,  5sPs  AMH  In  (D  }-  Message  Handing  System  (MHS)  Common  Massaging.  Pvt  3: 

Requirements  for  Message  Transfer  (Pi),  Draft,  1993  (sent  to  Navy  publications) 

MIL-STD-1 745-1 7501  -04,  DSPs  AMH  In  (D  )-  Message  Handling  System  (MHS)  Common  Messaging,  Part  4: 

Messaging  Requirements  for  MTS  Access  (P3),  Draft,  1993  (sent  to  Navy  publications) 

MIL-STD-1 745-1 7501  -05,  DSPs  AMH  In  (D  )-  Message  Handling  System  (MHS)  Common  Messaging,  Part  5: 

Messaging  Requirements  for  MS  Access  (P7).  Draft,  1993  (sent  to  Navy  publications) 

MIL-STD-1 745-1 7502,  MHS  Military  Messaging,  Content  Type  AMH  2n  (D),  Draft,  1993  (baseline  for  validation; 
requesting  approval  to  publish  from  DTMP) 

MIL-STD-1 745-1 7503-01,  DSPs  -  Internet  Message  Transfer  Profile  for  DoD  Communications,  Part  1:  Simple 
Mail  Transfer  Protocol  (in  SD-1  coordination) 

MIL-STD-1 745-1 7503-02,  DSPs  -  Internet  Message  Transfer  Profile  tor  DoD  Communications,  Part  2:  Format  of 
Text  Messages,  Draft,  1993  (in  SD-1  coordination) 

MIL-STD-1 745-1 7504,  DSPs  •  Internet  File  Transfer  Profile  for  DoD  Communications,  Draft,  1993  (in  SD-1 
coordination) 

MIL-STD-1 745-1 7505,  DSPs  -  Internet  Domain  Name  Service  (DNS)  Profile  for  DoD  Communications,  Draft,  1993 
(in  SD-1  coordination) 

MIL-STD-1 745-1 7506,  DSPs  -  Internet  Remote  Login  Profile  for  DoD  Communications,  Draft,  1993  (in  SD-1 
coordination) 

MIL-STD-1 745-1 7507-01,  DSPs-  Internet  Network  Management  Profile  for  DoD  Communications.  Parti:  Simple 
Network  Management  Protocol  (SNMP),  Draft,  1993  (in  SD-1  coordination) 

MIL-STD-1 745-1 7507-02,  DSPs  •  Internet  Network  Management  Profile  for  DoD  Communications,  Part  2: 

Management  Information  Base  (MIB),  Draft,  1 993  (in  SD-1  coordination) 

MIL-STD-1 745-17507-03,  DSPs  -  Internet  Network  Management  Profile  for  DoD  Communications,  Part  3: 

Structure  and  Identification  of  Management  Information,  Draft,  1993  (in  SD-1  coordination) 

MIL-STD-1 745-1 7508-01,  DSPs  AFT  In  (D)  -  File  Transfer.  Access  and  Management,  Part  1;  Specification  of 
ACSE,  Presentation  and  Session  Protocols  for  Use  by  FT  AM,  Draft.  1993  (in  SD-1  coordination) 

MIL-STD-1 745-1 7508-02,  DSPs  AFT  In  (D)  -  File  Transfer,  Access  and  Management,  Part  2:  Definition  of 
Document  Types,  Constraint  Sets  and  Syntaxes,  Draft,  1993  (in  SD-1  coordination) 

MIL-STD-1 745-1 7508-03,  DSPs  AFT  in  (D)  -  File  Transfer,  Access  and  Management,  Part  3:  AFT  11— Simple 
File  Transfer  Service  (Unstructured),  Draft,  1993  (in  SD-1  coordination) 

MIL-STD-1 745-1 7508-04,  DSPs  AFT  In  (D)  -  File  Transfer.  Access  and  Management  Part  4:  AFT  12— Positional 
File  Transfer  Service  for  Rat  Files,  Draft,  1993  (in  SD-1  coordination) 

MIL-STD-1 745-1 7508-05,  Information  Technology  -  Defense  Standardized  Profiles  AFT  In  (D)  -  File  Transfer, 
Access  and  Management,  Part  5:  AFT  22 — Positional  File  Access  Service  for  Rat  Rise,  Draft,  1993  (in 
SD-1  coordination) 

MIL-STD-1 745-1 7508-06,  DSPs  AFT  In  (D)  -  File  Transfer,  Access  and  Management  Part  8:  AFT  3 — File 
Management  Service,  Draft,  1993  (in  SD-1  coordination) 

8000-8eries— Network  Management 

MIL-STD-1 745-38000,  Government  Network  Management  Profile  (GNMP),  1991  (approved  and  published) 
MIL-STD-1 745-38000,  DoD  Network  Management  for  DoD  Communications,  Version  2  of  GNMP,  Draft  (working 
group  circulation),  DTMP/WG3, 1992 
8500-Series — Security 

MIL-STD-1 745-1 8500-01,  DSPs  AMH  Xn  (D)-  Message  Handing  System  (MHS)  Message  Security  Protocol, 
Part  1:  MSP  Service  Support  Draft,  DTMP/WG3, 1993  (sent  to  Navy  publications) 

MIL-STD-1 745-1 8500-02,  DSPs  AMH  Xn  (D)-  Message  Handling  System  (MHS)  Message  Security  Protocol, 
Part  2:  MSP  Content  Protocol,  Draft,  DTMP/WG3, 1993  (sent  to  Navy  publications) 

MIL-STD-1 745-1 8500-03,  DSPs  AMH  Xn  (0)-  Message  Handing  System  (MHS)  Message  Security  Protocol. 

Part  3:  MSP  Requirements  for  Message  Transfer,  Draft,  DTMP/WG3, 1993  (sent  to  Navy  publications) 
MIL-STD-1 745-1 8500-04,  DSPs  AMH  Xn  (D)-  Message  Handing  System  (MHS)  Message  Security  Protocol, 
Part  4;  MSP  Requirements  for  MS  Access,  Draft,  DTMP/WG3, 1 993  (sent  to  Navy  publications) 

MIL-STD-1 745-1 8500-05,  DSPs  AMH  Xn  (D)-  Message  Handing  System  (MHS)  Message  Security  Protocol, 
Part  5:  MSP  Requirements  for  MS  Access,  Draft,  DTMP/WG3, 1993  (sent  to  Navy  publications) 

MIL-STD-1 745-48501,  Common  Security  Label,  Draft.  1993  (in  SD-1  coordination! 

Source;  [Curdo  1994] 

16.1.7  Other  Profiles  and  Transition  Strategies 

This  section  is  intended  to  be  expanded  to  address  additional  activities  and  options  to 
support  transition  from  existing  military  and  other  standards  to  standards  for  open  environments. 
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Examples  are  application  gateways,  test  systems,  and  test  methodologies.  Efforts  to  highlight 
functional  standards,  select  stacks  of  mature  standards  and  options  within  standards,  and 
harmonize  implementations  will  be  examined.  One  example  is  the  Guide  to  the  Use  of  Standards 
(Ref.  SPAG  1987]  developed  by  SPAG  in  Europe.  Functional  standards  based  on  OSI  standards 
are  being  developed  by  the  Interoperability  Technology  Association  for  Information  Processing, 
Japan  (INTAP),  specifically  towards  an  interoperable  distributed  database  system.  [Ref.  Konoike 
1987]  Recommendations  for  functional  standards  and  cooperation  with  European  and  US 
organizations  and  companies  are  also  provided  in  Japan  by  POSI. 

16.1.8  US  Policy  on  Coexistence  and  Convergence  of  TCP/IP-OSI 

At  the  request  of  the  Office  of  Management  and  Budget  (OMB)  in  collaboration  with  the 
Federal  Networking  Council  and  Federal  Information  Resources  Management  Policy  Council, 
NIST  established  the  Federal  Internetworking  Requirements  Panel  (FIRP)  to  reassess  federal 
requirements  for  open  systems  networks  and  to  recommend  policy  on  the  Government’s  use  of 
networking  standards,  specifically  on  the  coexistence  of  TCP/IP  and  OSI.  FIRP’s  draft  report 
[Ref.  FIRP  1994]  concluded  that  no  single  protocol  suite  meets  the  full  range  of  government 
requirements  for  data  internetworking  and  makes  five  recommendations: 

•  The  role  of  oversight  and  integration  across  federal  agency  internetworking  activities 
should  be  strengthened  within  the  OMB. 

•  The  roles  and  responsibilities  for  fostering  standards  and  assessing  technological 
change  should  be  refocused  and  strengthened  by  the  Department  of  Commerce. 

•  The  roles  and  responsibilities  for  infrastructure  development  and  operations  to  support 
all  internetworking  services  from  advanced  research  and  development  to  leading  edge 
to  core/commodity  services  should  be  clearly  defined  and  formally  assigned  through 
the  Information  Infrastructure  Task  Force 

•  The  roles  and  responsibilities  of  affinity  groups  should  be  defined,  including  how  they 
are  created  and  coordinated  by  the  Government  Information  Technology  Services 
working  group. 

•  In  accordance  with  OMB  Circular  A-l  19,  Revised  October  1993,  voluntary  standards 
should  be  adopted  and  used  by  Federal  agencies,  and  international  standards  should  be 
considered  in  the  interests  of  promoting  trade.  The  current  GOSIP  policy  should  be 
modified  by  the  Department  of  Commerce  to  reflect  the  wider  range  of  international 
voluntary  standards  for  internetworking. 

16.2  OSI  Environments 

16.2.1  ISO  Development  Environment  (ISODE) 

ISODE  is  prototype  software,  developed  as  a  tool  to  study  OSI.  However,  in  the  current 
vacuum  of  OSI  implementations,  ISODE  has  become  a  default  reference  implementation  of  the  OSI 
upper-layers,  a  platform  for  deploying  OSI  services,  and  a  means  for  transitioning  from  TCP/IP  to 
OSI  protocols. 

The  ISODE  software  supports  various  OSI  protocols  and  applications.  ISODE  is  aligned 
with  US  GOSIP.  The  current  modules  include  the  following  [Ref.  Rose  1990]: 

•  OSI  transport  service  (TPO  on  top  of  TCP,  X.25,  and  the  CO  network  service;  TP4 
for  SunLink  OSI) 

•  OSI  session,  presentation,  and  association  control  services 

•  ASN.  1  abstract  syntax/transfer  notation  tools 
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•  OSI  reliable  transfer  and  remote  operations  services 

•  FT AM/FTP  gateway 

•  OSI  Directory  services 

•  OSI  VT  (basic  class  and  TELNET  profile). 

The  ISODE  Consortium  (see  Appendix  F,  Section  3.28)  was  formed  in  1992  to  take  charge 
of  further  development  of  ISODE  and  to  commercialize  it  [Ref.  OSN  1992o] 

16.2.2  COS/COSINE  Recommendations 

Initial  profiles  for  Corporation  for  Open  Systems  Interconnection  in  Europe  (COSINE) 
have  been  released.  These  profiles  are  summarized  in  Table  30.  In  addition  to  those  standards 
cited  in  die  table,  COSINE  is  evaluating: 

•  Virtual  Terminal,  ISO  9041  (with  AD2  screen  mode) 

•  EWOS  Profile  A/122  for  file  access 

•  Additional  message  handling  services  (ITU-TS  X.400- 1988) 

•  Job  Transfer  and  Manipulation  (JTM),  ISO  8832  and  ISO  8833. 


Table  SO.  Standards  for  COSINE  Prof! las 


Layer 

Refarancaa  for  Standarda 

7.  Application 

ENV  41204  (FTAM) 

ENV  41910  (Remote  Terminal  Access) 

EWOS  Profile  A/1 11  (File  Access) 

RARE  MHS  and  ITU-TS  X 400-1 684  MHS  Services 
Renx.  -  Job  Entry  (to  be  defined  in  EWOS) 

6.  Presentation 

(NuM  Layer) 

5.  Session 

(Nti  Layer) 

4.  Transport 

(Connection -Orient  ad) 

w.  PHnWOffK 

(Connection-Oriented) 

2.  Data  Link 

ITU-TS  X25-1984 

1.  Physical 

Local  Araa  Networks  (not  specified) 

16.3  Assessment  of  Coverage  by  Standards 

Findings  related  to  standardized  profiles  for  communications  services  are  the  following: 

*  Lack  of  capability  to  cross  between  connection-oriented  and  connectionless-mode 
services  in  OSI  profiles.  The  OSI  Reference  Model  has  been  revised  to  incorporate 
connectionless  services  (previously  treated  as  an  addendum).  Most  work  on  crossover 
is  being  addressed  by  transport  or  relay  bridges,  some  of  which  do  not  conform  to  the 
Reference  Model.  Tins  is  a  major  problem  for  interoperability  between  North  America 
(which  uses  predominantly  connectionless  modes)  and  Eu.  x  (which  uses 
predominantly  connection-oriented  modes).  As  an  example,  Uc  a.  _  UK  GOSIP  are 
not  compatible  and  no  progress  has  been  made  to  converge  these  efforts.  However, 
Version  2.0  of  US  GOSIP  includes  an  optional  connectionless  transport  service  and  an 
optional  connection-oriented  network  service  for  use  on  end-systems  connected  to 
X.25  networks  that  are  not  going  to  be  connected  to  local  area  networks. 

•  Few  international  standardized  nmfiles  fISPs)  have  been  adopted  bv  ISO.  Work  on 
FT AM  profiles  is  the  most  mature  and  three  of  the  FT AM  ISPs  have  been  adopted  by 
ISO.  EWOS  is  preparing  a  number  of  candidates  for  adoption  in  ISO,  but  these 
emphasize  connection-oriented  services.  Profile  work  in  NIST  is  progressing  rapidly. 
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but  the  products  are  not  yet  in  the  form  that  can  be  used  for  an  ISP.  Adoption  of 
common  ISPs  is  critical  to  the  compatibility  of  products  based  on  OSI  and  other  open 
system  protocols. 
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17.  STATUS  OF  NATO  OPEN  SYSTEM  DATA  DISTRIBUTION 

STANDARDS 

17.1  Introduction 

This  chapter  and  the  next  examine  NATO  efforts  to 
analyze,  specify,  and  implement  open  system  standards  and 
architectures  to  achieve  interoperability.  The  purpose  is  to 
(1)  assess  the  progress  being  made  in  NATO  to  incorporate 
military  requirements  in  international  standards  and  to  define, 
where  necessary,  extensions  to  those  standards,  and  (2)  identify 
the  NATO  standards  and  profiles  that  may  be  applicable  to 
ATCCIS  (and  other  CCISs).  Chapter  17  focuses  on  data 
distribution  and  therefore  on  the  work  of  TSGCE  Subgroup  9 
(SG9).  Chapter  18  addresses  analyses,  demonstrations,  tests, 
development,  and  other  initiatives  for  data  communications  and 
information  systems  to  achieve  interoperability  and  cost  savings 
through  multinational  cooperation.  National  initiatives  in  these 
areas  are  addressed  in  Chapter  19. 

This  section  is  followed  by  a  discussion  of  the  eight 
military  requirements  defined  by  TSGCE  SG9  (Section  17.2) 
and  an  overview  of  SG9's  organization  and  the  plans  and 
activities  of  the  working  groups  (WGs)  within  SG9 
(Section  17.3).  Section  17.4  assesses  the  status  of  draft  OSI 
ST AN  AGs.  The  chapter  concludes  with  a  summary  of  related 
standards  work  in  NATO  bodies  (Section  17.5)  and  the  overall 
assessment  (Section  17.6). 

17.2  Military  Requirements  for  NATO  OSI 

This  section  summarizes  the  requirements  associated  with  incorporating  military 
enhancements  into  open  systems  interconnection  (OSI)  standards.  Within  NATO,  this  work  has 
been  assigned  to  TSGCE  SG9.  General  information  on  NATO  and  international  standards  bodies 
concerned  with  OSI  standards  is  provided  in  Appendix  F. 

Beginning  in  February  1983,  a  number  of  military  requirements  have  been  identified  in 
NATO  that  are  not  adequately  covered  by  all  existing  OSI  standards.  Eight  military  features  were 
identified  in  die  NATO  Interoperability  Management  Plan  (NIMP)  [Ref.  NIMP 1988],  and  TSGCE 
SG9  has  recommended  that  the  OSI  Reference  Model  (STANAG  4250)  be  extended  to  provide 
support  for  these  features: 

•  Multihomed,  mobile  host  systems 

•  Multi-endpoint  connection 

•  Internetworking 

•  Network/system  management  functions 

•  Security 
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•  Robustness  and  quality  of  service 

•  Precedence  and  preemption 

•  Real-time  and  tactical  communications. 

Table  51  gives  the  description  of  the  eight  military  features81  as  provided  in  Use  ofOSl 
Standards  in  NATO — Strategic  and  Technical  Issues,  March  1988.  [Ref.  UK  1988] 

Table  51.  Eight  Military  Featurea  for  Enhancing  OSI  in  NATO 


(1 )  Multihomed  and  mobile  host  systems.  Multihoming  is  a  mechanism  for  attaching  an  end  system  to  two  or 
more  network  access  points  without  the  need  for  a  system  setting  up  a  call  to  it  to  be  aware  of  the  extra 
connectivity.  In  addition  to  enhancing  survivability,  this  facility  may  be  extended  to  support  'mobile  hosts* 
such  as  aircraft  and  ships. 

(2)  Mutti-endpoint  connections  Imutti-addressino:  multioeer  data  transmission  tMPDTfl.82  In  order  to  transmit 
data  to  a  number  of  recipients,  it  is  usually  necessary  to  establish  several  connections  and  send  separate 
copies  of  the  data  across  each  connection  in  turn.  More  efficient  use  is  made  of  the  communications 
resources  if  the  sender  has  to  transmit  only  one  copy  of  the  data.  The  network  then  takes  care  of  routing, 
control,  and  distribution  of  the  data. 

(3)  Internetworking.  Mechanisms  are  required  to  facilitate  the  interconnection  of  various  NATO  systems  at  the 
boundary  point  between  subnetworks. 

(4)  Network  or  system  management  functions.  Management  functions  are  required  that  may  be  of  greater 
sophistication  than  those  considered  satisfactory  for  civilian  networks.  Management  of  broken  networks 
in  which  layers  of  protocols  are  inoperable  and  fast  responses  to  changes  in  network  topology  are 
essential  to  maintain  important  connections. 

(5)  Security.  Protection  measures  are  required  to  prevent  unauthorized  access  to  information,  preserve  the 
integrity  of  data,  and  to  mitigate  against  denial  of  service.  [Note:  Security  includes  access  control, 
authentication,  integrity,  and  confidentiality.] 

(6)  Robustness  (resiliencel  and  quality  of  aerviCB.  The  range  of  quality  of  service  parameters  required  for 
military  systems  exceeds  that  cunently  permitted  within  commercial  OSI  networks.  In  particular,  in  order 
to  maximize  the  survivability  of  a  network,  the  NATO  aim  is  to  maintain  an  adequate  quality  of  service  to  the 
users  (or  at  least  to  users  operating  above  a  given  priority  level)  in  the  face  of  a  severely  damaged  or 
partitioned  network. 

(7)  Precedence  and  preemption.  In  order  to  minimize  congestion,  particularly  in  a  damaged  network  where 
resources  are  at  a  premium,  it  is  desirable  to  be  able  to  allocate  resources  on  the  basis  of  priority  levels 
assigned  to  the  connections  being  routed  through  the  congested  area.  A  facility  is  therefore  required  to 
associate  a  priority  level  with  a  connection  when  it  is  established. 

(8)  RMl-time  and  tactical  communications  Certain  applications  are  prepared  to  sacrifice  such  aspects  of 
quality  of  service  as  sequencing  and  guaranteed  deKvery  to  achieve  the  minimum  potable  transit  delay. 

Source:  Use  ot  OSI  Standards  in  NATO — Strategic  and  Tachnieal  /ssues.  Issue  2,  TSGCE  SG9,  March  1988, 

NATO  RESTRICTED. 


A  top-level  view  of  how  the  eight  military  features  identified  above  could  potentially  affect 
the  layers  of  the  OSI  Reference  Model  is  provided  in  Table  52.  The  entries  in  the  table  are  based 
on  the  most  recent  editions  of  the  draft  OSI  ST  AN  AGs  (see  Section  17.4). 


8 1  The  eight  military  features  are  listed  in  the  NATO  Interoperability  Planning  Document  [Ref.  N1PD  1993, 
Volume  III)  as  specific  military  requiremenis/features  that  must  be  considered  in  development  of  standards. 

82  As  indicated  in  Section  9.2.  work  in  ISO  on  MPDT  has  been  suspended  in  SC21/WG1.  The  completed  work 
is  planned  to  be  released  as  a  Technical  Report.  Canada  is  serving  as  the  point  of  contact  within  TSGCE  SG9 
for  maintaining  interest  in  MPDT  in  ISO.  Canada  has  introduced  a  draft  proposal  in  ISO  on  Multi-Party 
Communications  that  would  address  MPDT. 
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Table  12.  Impact  of  Military  Features  on  Lay  ora  of  081  Rafaranea  Modal 
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Sourcas:  Use  of  OSI  Standard*  In  NATO-Strategic  and  Tachnieal  issues,  Annax  6,  Summary  of 
Impact  of  Military  Feature  on  Layata  of  Rafaranea  Uodal,  TSGCE  SG9.  1  March  1968,  NATO 
UNCLASSIFIED;  Commantariaa  on  tha  STANAGa  of  WG1.  Contribution  by  Franca  to  TSGCE 
SG9/WG1.  Fabruary  1989,  NATO  UNCLASSIFIED;  tha  NATO  OSI  Security  Archkactura  (NOSA), 
March  1988,  NATO  UNCLASSIFIED;  and  recently  raiaasad  draft  OSI  STANAGa  (through 
Dacambar  1991). 


17.3  Organizational  Responsibilities — TSGCE  Subgroup  9 

Current  SG9  Organization.  TSGCE  SG9  has  the  primary  responsibility  in  NATO  for 
reviewing  the  military  requirements,  identifying  the  potential  impact  on  the  OSI  standards  planned 
for  use  in  each  of  the  seven  layers  of  the  ISO  and  NATO  Reference  Model,  defining  the 
deficiencies  and  services  requited  to  address  these  requirements  at  each  layer,  and  developing  draft 
STANAGs  that  conform  to  the  Reference  Model  and  provide  for  the  needed  services.  As  a  result 
of  the  1991  TSGCE  reorganization,  SG9  has  three  permanent  WGs,  three  ad  hoc  working  groups 
(AHWGs),  and  one  project  group  (PG)  [Ref.  TSGCE  1991b;  Curcio  1994]: 

•  WG4  on  Data  Links— established  in  1991  to  consider  future  data  lines  and  data  link 
architectures.  AHWGs  have  been  formed  under  WG4  to  deal  with  Data  Link 
Interoperability  and  Data  link  Testing. 

•  WGS  on  OSI  Layers  1-4 — responsible  for  networking,  with  specific  responsibility  for 
transport  and  relay  profiles. 

•  WG6  on  Upper  Layers  and  Pan-Layer  Issues — responsible  for  such  issues  as 
security,  network  management,  quality  of  service,  conformance,  naming  and 
addressing;  and  for  application  profiles.  Note:  the  work  of  the  former  AHWG  on 
Network  Management  was  completed  in  June  1993;  any  further  activity  on  network 
management  will  be  done  by  WG6. 

•  AHWG  on  Integrated  Services  Digital  Network  (ISDN),  subordinate  to  WG5 — 
developing  STANAGs  for  using  ISDN  standards  developed  through  ITU-TS. 

•  AHWG  on  Military  Message  Handling  System  (MMHS),  subordinate  to  WG6 — 
developing  MMHS  profiles,  which  are  expected  to  be  completed  in  1994. 

•  AHWG  on  Security — responsible  for  providing  security  architecture/standards  and 
guidance  to  other  groups  as  agreed  by  the  SG9  plenary. 

•  Project  Group  (PG)  9  on  Multifunctional  Information  Distribution  System  (MIDS) 
Low  Volume  Terminal  (LVT) — not  a  permanent  WG;  PG9  was  disbanded  at  the  aid 
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of  1993,  and  a  NATO  Project  Steering  Committee  was  established  under  the  terms  of  a 
memorandum  of  understanding  (MOU). 

TSGCE  SG9  maintains  liaison  with  many  NATO  bodies  and  agencies,  including  ADSIA, 
TSGCE  SGI  1  (Tactical  Communications),  TSGCE  PG6  (Tactical  Communications  Systems  for 
the  Land  Combat  Zone — Post  2000),  NATO  Industrial  Advisory  Group  (NIAG)  SG6 
(Compatibility  of  Naval  Data  Handling  Equipment),  ATCCIS  PWG,  and  Allied  Tactical 
Communications  Agency  (ATCA).  Liaison  will  be  initiated  with  the  newly  formed  TSGCE  SGI 2 
on  Information  Systems,  together  with  its  two  subordinate  groups:  WG2  on  Data  Processing  and 
Management  and  the  AHWG  on  ATCCIS.  (The  work  of  SGI  1,  PG6,  and  SG12  is  discussed  in 
Chapter  18.) 

A  concern  about  the  current  structure  of  SG9  is  the  level  of  participation  by  the  nations. 
For  example,  during  the  period  July  1992  through  December  1993  only  five  nations  (GE,  NE, 
NO,  UK.  and  US)  participated  in  more  than  half  of  the  six  semiannual  meetings  of  WGS,  and  only 
one  of  these  meeting  had  as  many  as  seven  participating  nations.  Only  six  nations  attended  the 
October  1992  SG9  plenary,  and  only  seven  nations  attended  the  May  and  October  1993  SG9 
plenaries.  Canada  has  greatly  reduced  its  previously  very  active  role  due  to  limited  resources  (but 
is  still  very  active  in  the  AHWG  on  Security).  Resource  limitations  may  affect  other  nations  in 
1994  and  1995.83  Another  concern  is  the  lack  of  substantive  STANAGs  to  provide  the  basis  of 
NATO  cooperation  for  the  use  of  OSI  standards  in  military  systems.  Many  of  the  OSI  STANAGs 
(and  all  of  those  now  ratified)  are  principally  cover  sheets  for  international  civil  standards,  and  this 
is  true  of  several  other  STANAGs  still  in  draft  form.  The  new  focus  of  SG9  on  profiles  appears 
more  substantive,  but  it  is  not  clear  if  any  of  the  nations  are  prepared  to  mandate  the  use  of  the 
emerging  profiles.  The  key  to  cost-effective  implementation  is  in  influencing  vendor  products, 
which  has  been  primarily  driven  by  regional  and  international  civil  consortia  of  vendors, 
governments,  and  users;  it  is  not  clear  whether  TSGCE  recommendations  and  standards  will 
influence  the  commercial  products. 

TSGCE  Reorganization.  In  May  1993,  in  response  to  direction  from  its  parent 
organization,  the  Conference  of  NATO  Armaments  Directors  (CNAD)  [Ref.  Beard  1993],  a  new 
structure  and  organization  for  TSGCE  has  been  proposed  based  on  guidance  provided  by  the 
NATO  International  Military  Staff  (IMS)  [Ref.  Klein  1993].  The  CNAD  is  seeking  to  restructure, 
streamline,  and  make  more  effective  the  organization  and  working  practices  of  its  Main  Groups 
(such  as  the  TSGCE).  The  goal  is  to  provide  more  effective  contributions  by  the  Main  Groups  to 
the  process  of  collective  armament  planning.  Each  Main  Group  has  been  directed  to  revise  its 
terms  of  reference  (TOR),  with  organization  based  on  the  following  elements  [Ref.  Klein  1993]: 

•  Main  Group  promotes  cooperation  and  technology  development,  procurement,  and 
standardization  dud  may  lead  to  future  military  equipment  and  systems 

•  Standing  Groups  (SG)  of  the  Main  Group  that  concentrate  on  information  exchange 
and  direct  supervision  and  management  of  subordinate  groups 

•  Ad  Hoc  Groups  (AHGs),  established  initially  for  2  years,  which  provide  the  basis  for 
armaments  cooperation  under  the  Main  Groups  and  which  actively  develop  STANAGs 
in  conduction  with  pursuing  materiel  standardization  activities  (some  may  be  specially 
approved  as  open  ended) 


83  In  its  May  1993  plenary.  TSGCE  SG9  noted  the  reduction  in  participation  in  WGs  5  and  6;  this  issue  was  to 
be  raised  by  the  SG9  Chau  at  the  next  TSGCE  plenary. 
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•  Project  Groups  (PGs),  which  may  be  formed  when  a  cooperative  venture  has  been 
identified  and  when  interested  nations  have  agreed  to  commit  resources  to  a  joint 
effort 

The  Chair  of  TSGCE  has  proposed  the  following  standing  groups  for  TSGCE  as  a  Main 
Group  [Ref.  Gladman  1993]: 

•  Communications  Systems  Group  formed  from  SGI  1  and  part  of  SG9 

•  Information  Systems  Group  formed  from  SGI 2  and  part  of  SG9 

•  Combat  Support  Systems  Group  formed  from  SG4  and  SG5. 

These  standing  groups  would  be  responsible  for  (1)  organizing  information  exchange  within  their 
areas  in  order  to  promote  cooperative  equipment  and  systems  development  opportunities; 

(2)  identifying  possible  opportunities  for  cooperative  equipment  or  systems  development; 

(3)  establishing  and  managing  temporary  working  groups  to  investigate  such  opportunities  in 
more  detail;  (4)  identifying  standardization  objectives  within  their  areas  for  which  the  nations  are 
prepared  to  find  resources  and  funds;  and  (5)  establishing  working  groups  to  develop  such 
standards. 

The  following  working  group  structure  has  been  proposed  [Ref.  Gladman  1993]: 

•  Communications  Systems  Group 

Tactical  Communications  (a  combination  of  WGs  in  SG11) — should  bring 
together  national  experts  to  decide  where  real  cooperative  possibilities  exist 
Fixed  (Strategic)  Communications  (WGS  and  AHWG  on  ISDN  in  SG9) 

Satellite  Communications  Systems  <WG8  of  SGI  1) 

•  Data  Links  (WG4  of  SG9) 

•  PG*4  on  Tactical  Communications  Post  2000  (PG6) 

PG  on  Communications  System  Network  Interoperability  (CNSI) 

PG  on  Multifunctional  Information  Distribution  System  (MIDS)  (PG9) 

•  Information  Systems  Group 

Electronic  Mail  and  Messaging  (AHWG  on  MMHS  in  WG6  of  SG9) 

Distributed  Information  Systems  (a  combination  of  WGs  in  SG9;  responsible  to 
the  TSGCE  but  with  tasking  link  to  the  ISWG  of  the  NACISQh-coveis  an  area  of 
technology  (including  information  systems  security)  that  is  vital  to  C3  systems 
effectiveness  and  that  should  form  a  part  of  the  TSGCE  effort;  while  cooperating 
with  other  NATO  agencies  (e.g.,  NSA,  ACCSA),  the  TSGCE  will  have  a  lead 
role  in  technical  standardization;  this  working  group  would  also  be  tasked  by  the 
ISWG 

Information  Systems  Engineering  (responsible  to  the  ISWG  of  the  NACISC  but 
with  a  tasking  link  to  the  TSGCE) — covers  systems  and  software  engineering, 
including  acquisition  methods  and  approaches 
PG  on  BICES 

PG  on  Ada  Programming  Support  (SWG  on  APSE) 

•  Combat  Support  Systems  Group 

Identification  Systems  (SG5) 

Navigation  Systems  (SG4). 

The  Chair  TSGCE  observed  in  a  commentary  on  existing  groups  [Ref.  Gladman  1993]  that 
(1)  SG9  currently  has  an  extensive  number  of  working  groups  but  very  little  in  the  way  of  real 


14  He  TSGCE  Chair  soled  that  the  five  proposed  PGs  are  all  cvneady  worictag  mder  moltinattooal  OMBKnnda 
of  andentmdtag  and  repot  dkectty  id  the  nations  involved  md  not  to  the  TSGCE  (Ref.  Ghdnun  1993]. 
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cooperation  in  actual  systems  development;  (2)  the  standards  work  has  been  of  high  quality  but  its 
exploitation  by  the  nations  has  been  limited  and  painfully  slow;  (3)  its  seems  likely  that  many 
nations  will  not  implement  the  standards  being  evolved  and  this  should  be  a  major  concern  to  the 
TSGCE;  and  (4)  the  focus  now  needs  to  shift  away  from  standards  to  cooperation  on  the  programs 
for  which  such  standards  are  needed. 

Regarding  SG11  on  Communications  Systems,  the  Chair  TSGCE  observed  [Ref. 
Gladman  1993]  that  (1)  SGI  1  has  a  wide  range  of  activities  in  the  land  tactical  communications 
area  but  it  is  difficult  to  discern  any  strategy  or  coherence  in  these  efforts  when  viewed  as  a  whole; 
and  (2)  in  the  satellite  communications  field,  the  nations  are  extensively  involved  in  major 
discussions  of  possible  cooperation  in  the  next  generation  satellite  communications  systems  but 
entirely  outside  the  TSGCE  framework. 

The  Chair  TSGCE  proposed  that,  when  approved  by  the  TSGCE,  the  new  Standing 
Groups  should  be  established  immediately  and  that  TORs  and  proposed  working  group 
recommendations  be  submitted  to  the  second  TSGCE  meeting  in  1994. 

Other  Concerns.  A  view  of  the  TSGCE  SG9  Chair  on  the  long-term  strategy  for  NATO 
standardization  (based  on  the  ODP  five-view  model)  is  provided  in  Section  18.9.1.  A  number  of 
OSI  issues  of  concern  to  NATO  organizations  and  being  addressed  in  TSGCE  SG9  are  discussed 
in  Section  18.9.4  (on  OSI)  and  Section  18.9.5  (on  ISDN).  The  needs  of  various  NATO 
initiatives  for  standards  being  addressed  in  TSGCE  are  identified  in  Sections  18.2  to  18.8. 

17.3.1  NATO  Reference  Models,  Transition  Strategy,  and  NOSIP  Strategy 

17.3.1.1  NATO  Reference  Models 

STANAG  4250,  NATO  Reference  Model  for  Open  Systems  Interconnection  (NATO  RM 
OSI),  Edition  2,  was  last  ratified  and  promulgated  by  the  Military  Agency  for  Standardization  in 
August  1990  (M AS/2 1 2-EL/4250)  as  Part  1:  General  Description.  A  third  edition  has  been 
developed  [DS(CCC-ICP)(93)703,  November  1993]  but  not  yet  distributed  for  ratification.  One 
of  the  outstanding  issues  in  1993  was  whether  the  name  of  STANAG  4250  should  be  changed  to 
NATO  Reference  Model  for  Open  Systems  Information  Interchange  and  its  scope  broadened  to 
include  a  reference  model  for  voice  and  video  communications  [e.g.,  Integrated  Services  Digital 
Network  (ISDN)].  Agreement  was  not  reached  on  this  change  in  the  October  1993  plenary  of 
TSGCE  SG9,  so  the  development  of  a  reference  model  to  address  ISDN  and  related  services  will 
be  continued  as  a  separate  document. 

The  parts  and  status  of  STANAG  4250  are  as  follows: 

•  STANAG  4250-1  (Part  1):  General  Description,  Edition  2  of  STANAG  4250, 
MAS/212-EL/4250,  August  1990  (ratified  and  promulgated)  (cf.  ISO  7498-2) 

•  STANAG  4250-1.3  (Part  1):  Basic  Reference  Model,  Edition  3  of  STANAG  4250, 
Draft,  DS(CCC-ICP)(93)703  (distributed  for  staffing),  November  1993  (cf. 
ISO  7498-2) 

•  STANAG  4250-2  (Part  2):  Security,  December  1993,  NATO  SECRET  (submitted  for 
staffing,  final  editing,  and  translation  prior  to  distribution  for  ratification)  (cf. 
ISO  7498-2) 

•  STANAG  4250-3  (Part  3):  Naming  and  Addressing,  Draft,  DS(CCC-ICPX93)1 17 
(distributed  for  staffing)  and  AC/302-D/647  (distributed  for  ratification),  March  1993 
(cf.  ISO  7498-3)  (as  of  25  January  1994,  ratified  by  four  nations) 
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•  STANAG  4250-4  (Part  4):  Management,  Draft,  DS(CCC-ICP)(93)1 129  (distributed 
for  staffing)  and  AC/3G2-D/648  (distributed  for  ratification),  26  April  1993,  NATO 
UNCLASSIFIED  (cf.  ISO  7498-4,  10040)  (as  of  25  January  1994,  ratified  by  four 
nations). 

Three  additional  documents  have  been  drafted  as  a  new  part  of  STANAG  4250,  but 
agreement  to  distribute  these  drafts  has  failed  in  each  case. 

•  Military  Factors,  Draft  (preliminary),  1992  (submitted  as  Part  5;  cancelled  May  1993) 

•  NSP  Guidelines,  Draft  (preliminary),  1992  [submitted  as  Part  6;  rejected  by  TSGCE 
SG9  plenary  in  December  1992  and  cancelled  in  May  1993;  when  this  document 
becomes  stable  (sometime  in  1994),  it  will  be  subsumed  into  die  NOSIP  Strategy] 

•  NATO-Adopted  Civil  Standards,  Draft  (preliminary),  October  1993  (submitted  as 
Part  5;  work  suspended  by  action  of  TSGCE  SG9  in  October  1993). 

17.3.1.2  NTIS  Transition  Strategy 

A  major  project  of  TSGCE  SG9,  led  by  the  German  delegation,  is  the  development  and 
maintenance  of  the  NTIS  Transition  Strategy.  The  current  version  is  the  1991  or  Sixth  Edition;  it 
is  dated  November  1991  [Ref.  NATO  1991]  and  was  accepted  by  SG9  in  December  1991.  This 
document  provides  recommendations  for  international  commercial  standards,  primarily  from  ISO 
and  ITU-TS,  and  intercept  strategies  (stacks  of  standards)  that  can  be  used  by  the  nations  as  part  of 
a  transition  strategy  prior  to  the  promulgation  of  OSI  ST AN  AGs. 

As  noted  in  the  January  1992  release  (Edition  3)  of  WP  25,  the  following  emerging 
standards  not  addressed  in  the  Fifth  or  Sixth  Edition  should  be  considered:  ODP,  TM,  security 
protocols,  X-Protocol  (X-Windows),  GKS,  CGI,  PHIGS,  CGM,  SQL,  ERDS,  and  RPC. 

17.3.1.3  NOSIP  Strategy 

The  NATO  Open  System  Interconnection  Profile  (NOSIP)  Strategy,  Draft, 
September  1993,  has  been  developed  and  distributed  to  the  nations  by  TSGCE  SG9  for  review 
comment  [Ref.  NATO  1993a]  in  order  to  facilitate  the  identification,  specification,  acceptance,  and 
procurement  of  military  communications  and  information  systems  based  on  the  use  of  commercial 
off-the-self  (COTS)  products  that  use  international  civil  standards.  When  endorsed  by  the 
Conference  of  NATO  Armaments  Directors  (CNAD),  which  is  die  parent  body  of  die  TSGCE,  die 
NOSIP  Strategy  will  be  a  mandatory  source  of  NATO  Technical  Interoperability  Standards  (NTIS) 
in  support  of  the  NATO  Interoperability  Management  Plan  (NIMP)  and  die  NATO  Interoperability 
Planning  Document  (NIPD).  (The  current  CNAD-endorsed  source  for  NTIS  is  the  NTIS 
Transition  Strategy  [Ref.  NATO  1991].)  The  NOSIP  Strategy  applies  to  the  procurement  and 
installation  of  all  NATO  communications  and  information  systems  that  provide  or  support  NTIS. 
It  also  applies  to  national  systems  and  components  that  must  interoperate  with  NATO  systems  and 
with  each  other.  The  NOSIP  Strategy  was  developed  to: 

•  Achieve  interoperability 

•  Maximize  the  exploitation  of  COTS  products 

•  Reduce  the  proliferation  of  non-standard  systems. 

NOSIP  is  intended  to  provide  an  overall  framework  for  NATO  communications  that 
addresses  the  requirement  to  provide  different  types  of  communication  services  and  to  support 
different  types  of  applications  over  a  variety  of  network  types.  The  current  version  of  the  NOSIP 
Strategy  focuses  on  OSI-  and  ISDN-based  communications;  other  subnetwork  technologies  will  be 


Chapter  17 


367 

UNCLASSIFIED 


NATO  OSI  Standardization 


UNCLASSIFIED 


included  in  future  versions  of  the  document  The  three  objectives  of  the  NOSIP  Strategy  are  as 
follows: 

(1)  To  state  NATO  policy  on  the  use  of  standards  for  communications  for  interoperable 
systems  within  NATO 

(2)  To  provide  a  framework  for  the  development,  management,  and  use  of  NTIS  to 
achieve  interoperability  among  NATO  systems 

(3)  To  provide  direction  to  assist  in  the  procurement  and  acceptance  of  interoperable 
NATO  systems. 

The  NOSIP  Strategy  seeks  to  achieve  these  objectives  by  providing  the  following  advice: 

•  Recommendations  for  a  standardized  internetworking  communications  architecture 

•  List  of  standardized  profiles  and  other  communications  standards  to  be  used  by  the 
NATO  member  forces 

•  Guidance  on  the  use  of  interim  and  intercept  standards 

•  Guidelines  for  improving  interoperability  among  NATO  systems 

•  Guidance  for  procurement  agencies  and  officials  on  the  selection  and  use  of  the  NTIS. 

Several  principles  provide  the  underpinning  for  the  NOSIP  Strategy.  They  are  die 

following: 

•  Promoting,  to  the  maximum  extent  possible,  open  systems  civil  profiles  and  COTS 
products 

•  Promoting  adoption  of  military  requirements  into  the  civil  sector  standardization 
process 

•  Promoting  the  selection  and  use  of  applicable  civil  international  profiles  (NATO 
standardized  profiles  will  be  created  only  where  existing  civil  profiles  are  inadequate) 

•  Rationalizing  the  required  range  of  interconnection  services  within  a  common 
architecture 

•  Recommending  a  subset  of  available  standards  and  profiles  to  increase  die  ability  of 
NATO  systems  to  interoperate 

•  Encouraging  the  adoption  of  NOSIP  specifications  as  a  mandatory  part  of  the 
procurement  policy  of  NATO  member  nations. 

The  scope  of  NOSIP  includes  most  of  what  was  formerly  the  NTIS  Transition  Strategy, 
but  with  greater  attention  to  the  NATO  C3  environment,  architectural  requirements  and  issues, 
profiles  (using  ISO  taxonomy),  and  procedural  issues.  Upon  publication  of  the  NOSIP  Strategy, 
the  NTIS  Transition  Strategy  will  be  considered  to  be  subsumed  by  the  NOSIP.  The  NOSIP 
Strategy  comprises  five  parts: 

•  Part  I,  Overview — discusses  the  NATO  C3  Environment,  which  includes  reference  to 
the  NATO  C3  Architecture,  the  NATO  Tactical  Communications  Architecture — Post 
2000,  and  the  eight  military  features 

•  Part  II,  Architecture — discusses  the  NATO  Reference  Model  (which  includes  both  die 
OSI  Reference  Model  and  the  CCITT  ISDN  Reference  Model),  security,83  naming  and 
addressing,  network  and  systems  management,  and  profiles 

•  Part  m,  NOSIP  Standards — specifies  and  discusses  those  standards  that  have  been 
approved  for  NATO  use  as  NTIS,  summarizes  the  taxonomy  of  profiles  being  used 


83  ST  AN  AG  4250-2,  NATO  OSI  Security  Architecture,  is  still  under  development.  The  most  reoat  draft  is 

Version  4.0,  NATO  OSI  Reference  Model,  Put  2:  Security,  9  December  1993.  See  Section  11.2.3.2. 
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for  NATO  (adapted  from  the  ISO  taxonomy),  and  provides  a  95-item  list  of  base 
standards  and  profiles  for  OSI  and  ISDN  interconnections 

•  Part  IV,  Procedural  Issues — identifies  procedures  for  naming  and  addressing, 
registration,  testing,  and  configuration  management  (see  Sections  9.1.2,  12.2,  and 
12.3) 

•  Part  V,  Procurement  Guidance — relates  the  NOSIP  Strategy  to  various  GOSDPs, 
specifies  applicability  criteria,  and  provides  recommendations  for  use  of  the  document 
in  procurements. 

Details  of  the  current  recommendations  of  the  NOSIP  Strategy  are  provided  in  WP  25  in 
several  ways.  The  list  of  base  civil  standards  is  identified  in  Appendixes  D  and  E  with  special 
marks  to  show  that  a  standard  is  included  in  NOSIP.  In  addition.  Appendix  I  portrays  the  profiles 
provided  in  NOSIP.86  Other  documents  cited  in  NOSIP,  such  as  STANAG  4250  and  the  OSI 
STANAGs  4251-59  and  4261-66,  are  listed  in  Appendix  H  and  discussed  in  detail  in  Appendix  J. 

17.3.2  WG4  Activities  and  Plans  for  Data  Link  Standards 

17.3.2.1  WG4  Activities 

The  first  meeting  of  SG9/WG4  on  Data  Links  was  held  in  June  1991;  five  nations  (FR, 
GE,  NO,  UK,  US)  participated  in  the  December  1991  meeting.  WG4  was  created  within  SG9  to 
address  such  data  link  topics  as  media-independent  data  link  architecture  (MIDLA),  Multifunctional 
Information  Distribution  System  (MIDS),87  unmanned  aerial  vehicles  (UAVs),  stand-off 
surveillance,  target,  and  acquisition  (SOSTA)  systems,  and  reconnaissance,  surveillance,  and 
target  acquisition  (RSTA)  systems. 

Germany  is  joining  France  and  the  United  Kingdom  in  Phase  2  of  MIDLA.  When  Phase  2 
is  completed,  it  is  expected  that  MIDLA  participants  will  provide  a  recommendation  to  the  TSGCE 
that  tasks  be  initiated  to  prepared  necessary  STANAGs. 

The  primary  activity  of  WG4  has  been  the  review  and  coordination  of  STANAG  4175  to 
bring  it  into  line  with  the  Joint  Tactical  Information  Distribution  System  (JTIDS)  terminal. 

WG4  has  been  discussing  interoperability  testing  efforts,  principally  among  nations 
implementing  JTIDS  or  MIDS.  Interoperability  testing  issues  are  being  addressed,  in  part,  in  the 
MIDS  Interoperability  Interface  Working  Group,  subgroup  of  PG9  on  MIDS-LVT. 
Interoperability  testing  is  viewed  as  a  national  responsibility,  since  NATO  funds  cannot  be  used  for 
international  testing.  Risk  reduction  testing  will  include  use  of  facilities  of  the  US  Joint 
Interoperability  Test  Center  (JITC)  at  Fort  Huachuca,  Arizona. 

A  classified  memorandum  on  Data  Link  Requirements  prepared  by  the  NATO  International 
Military  Staff  has  been  provided  for  review  (October  1992);  comments  were  provided  prior  to  the 
January  1993  TSGCE  plenary. 

17.3.2.2  WG4  Work  Plan 

WG4  has  accepted  responsibility  for  the  maintenance  and  configuration  management  of 
STANAG  4175  on  MIDS;  currently  (December  1991)  ratified  by  10  nations,  STANAG  4175  will 


86  Many  of  the  profiles  specified  by  NOSIP  are  summarized  in  Appendix  1. 

87  MIDS  Is  a  NATO  form  of  the  Joint  Information  Distribution  System  (JTIDS)  developed  in  tbe  US.  The 
initial  implementation  in  NATO  used  tbe  Interim  JTIDS  Message  Standard  (UMS),  which  is  not  interoperable 
with  JTIDS.  While  there  are  significant  differences  in  hardware,  the  future  message  standard  for  MIDS 
(STANAG  417S)  is  essentially  the  same  as  the  TADIL  J  used  in  JTIDS. 
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be  promulgated  shortly.  WG4  will  address  other  data  link  issues  such  as  NATO  Improved  Link 

Eleven  (NILE)  and  UAVs.  There  was  specific  interest  in  investigating  solutions  to  the  UAV  data 

link  requirements  but  no  interest  in  discussion  of  MIDLA  (see  Section  17.S.1  for  discussion  of 

MIDLA  and  other  topics  originally  proposed  for  Nunn  Amendment  funding).  The  tasking  • 

assigned  to  WG4  is  summarized  in  Table  53.  WG4  is  currently  focusing  on  issues  relevant  to  the 

introduction  of  MIDS  nationally  and  in  NATO  and  what  the  group  should  do  to  assist  in  that 

process.  [Ref.  Ahem  1991] 

Table  S3.  SG9  Tasking  Instructions  for  WG4  on  Data  Links  0 

•  To  sponsor  and  develop  technical  interoperability  standards  for  data  linlcs;  control  required  test  and 
configuration  management  of  data  link  standards;  and  promote  their  use  to  avoid  unnecessary  proliferation  of 
application  specification  data  link  equipment  and  systems 

•  To  plan,  initiate,  and  coordinate  development,  testing,  and  implementation  of  interoperable  data  link  equipment 
and  systems 

•  To  provide  advice  for  the  TSGCE  on  all  matters  related  to  data  links 

•  To  maintain  configuration  control  of  ST ANAG  41 75  and  collate  implementatiorVtransition  plans  for  the 
introduction  of  the  MIDS  within  the  nations  and  NATO;  monitor  its  implementation;  and  identify  areas  for 
cooperative  activities  with  the  aim  of  initiating  such  activities 

•  To  explore  the  subject  of  media  independent  data  link  architecture  based  on  a  layered  structure 

•  To  explore  the  use  of  an  existing  or  initiate  the  development  of  a  technical  interoperability  standard  for  a 
common  data  link  for  UAVs,  SOSTA,  and  RSTA. 

Source:  WG4  on  Dmtm  Links  Report  to  the  Chairmen  of  SG9,  AC/302(SG/9)D/96,  Chairman  WG4,  December  1991, 
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17.3.3  WG5  Activities  and  Plans  for  Networking  Standards8* 

17.3.3.1  WG5  Activities 

The  following  activities  have  been  reported  by  participants  in  SG9/WG5: 

•  In  lieu  of  any  further  work  on  layer  STANAGs,  working  on  profiles  to  meet  NATO 
requirements. 

•  Revising  the  draft  STANAG  4250-1  to  include  the  ISDN  Reference  Model  as  well  as 
the  OSI  Reference  Model. 

•  Working  with  WG6  to  revise  the  NSP  Guidelines  Document  (planned  to  become 
STANAG  4250-6).  This  document  is  viewed  in  SG5  as  “a  basis  for  the  lowest 
common  denominator  of  interoperability.”  In  1992  SG9  rejected  including  this 
document  as  Part  6,  in  part  because  of  the  strong  resistance  by  application  profile 
developers  on  the  use  of  these  guidelines  (it  was  seen  as  not  broad  enough  to 
accommodate  WG6  profiles  as  well  as  profiles  not  based  on  the  OSI  Reference 
Model).  The  primary  concern  is  with  the  base  document,  ISO/TR  10000,  which 
prescribes  a  format  different  from  that  endorsed  by  EWOS.  If  current  work  in  ISO  to 
incorporate  the  EWOS  format  is  successful,  most  of  the  concerns  with  the  NSP 
Guidelines  Document  will  be  resolved.  The  NSP  Guidelines  Document  was  updated 
in  October  1993  and  sent  to  SG9  for  approval.  Once  approved,  it  will  be  subsumed 
in  the  NOSIP  Strategy.  [Ref.  Curcio  1994] 

•  Submitted  (May  1993)  four  lower  layer  STANAGs  to  IMS  for  ratification  when 
translation  is  complete:  425 1 , 4252, 426 1 ,  and  4262. 


88  This  section  is  based  on  the  following  sources:  (Onufer  1992a),  [Onufer  1992b],  [Messina  1993a], 
(Messina  1993b).  (Messina  1993c],  and  (Messina  1993d], 
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•  Distributed  (May  1993)  two  lower  layer  STANAGs  for  editing  and  agreement  4253 
and  4254.  Requested  that  STANAGs  4253  and  4254  be  Finalized  and  forwarded  to 
die  SG9  secretary  for  ratification. 

•  Distributed  a  multi-part  draft  STANAG  for  TCllll(M)  and  TC1121(M),  which 
describe  permanent  access  to  a  packet-switched  data  network  using  the  COTS  and 
CONS.  [Ref.  Curcio  1994] 

•  Preparing  ISDN  STANAGs  for  final  comment  preceding  ratification:  4459, 4460, 
4461, 4462,  and  4463. 

•  Preparing  NSP  STANAGs  for  final  comment  preceding  ratification:  4407, 4408,  and 
4409.  STANAGs  4408  and  4409  have  been  distributed  for  ratification. 

•  WG5  has  recognized  the  importance  of  a  LAN-to-ISDN  interface  to  support  the  NATO 
C3  Architecture.  STC  submitted  a  proposal  in  1992  for  a  RA5n.4nnn(M)  profile  to 
address  this  requirement,  and  agreed  to  produce  a  draft  RA5n.421n  profile.  This 
profile  would  make  use  of  ES-to-IS  routing,  IS-to-IS  routing,  and  the  Inter-Domain 
Routing  Protocol  in  the  Network  Layer  to  support  the  connectionless  network 
protocol.  This  work  appears  in  draft  STANAG  4413. 

•  Evaluating  and  preparing  comments  on  draft  STANAG  4250-7  (formerly  planned  as 
an  annex  to  4250-1)  on  NATO-Adopted  Civil  Standards ,  with  the  recommendation 
that  standards  cited  in  this  document  requires  no  further  work  in  SG9. 

•  Commenting  on  document  produced  by  SG9  secretariat  on  data  links. 

•  Addressing  multicast  service,  which  is  designed  to  provide  more  efficient  transmission 
of  identical  data  to  two  or  more  destinations,  primarily  to  conserve  bandwidth  and 
possibly  reduce  delays  in  transmission.  [The  US  provided  WG5  the  status  of  US 
proposals  in  ISO  to  extend  the  connection-oriented  transport  protocol  (ISO  8473)  to 
incorporate  reliable  multicast  services.]  [Ref.  Curcio  1994] 

17.3.3.2  WG5  Work  Plan 

The  current  draft  work  plan  for  WG5  identifies  the  following  activities  for  1994  [Ref. 

Onufer  1993]: 

•  NOSIP 

Manage  lower  layer  standards  status 
NSP  Guidelines  in  NOSEP 
Extensions  to  ISO  taxonomy  of  profiles 

•  NATO  and  national  networks 

Identify  interoperability  requirement  (e.g.,  MC  277) 

Make  recommendations  on  NATO  Networking  Architecture 

•  Profiles 

Relay  ISDN-LAN  9  (to  be  completed  April  1995) 

-  Relay  X.25-LANCTBD) 

Subnetwork-related  profiles  (TBD) 

•  Security 

Implementation  in  profiles  (TBD) 

•  Base  standards 

CO  protocols  (routing,  subnetwork  independent)  (TBD) 

Revision  of  8473,  including  SNIP  (under  development;  completion 
October  1994) 

Multicasting  (under  development;  completion  April  1995) 
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•  Management 

Produce  managed  object  definitions  for  military  enhancement  (under 
development;  completion  October  1994) 

•  ISDN 

Prepare  tasking  for  the  AHWG  on  ISDN,  approve  the  work  plan,  and  approve 
output  documents  (ongoing) 

•  Liaison  with  WG6,  SG11  (WG1).  CNSI  project,  SG9  AHWGs,  PG6,  and  NIAG 
SG6  (ongoing). 

17.3.3.3  Areas  Not  Yet  Addressed  In  WG5  Work  Plan 

NACISA  has  promulgated  a  policy  statement  that  makes  the  use  of  CLNP  and  TP4 
mandatory  for  all  NATO  infrastructure  programs.  This  is  of  concern  to  members  of  WGS  (e.g., 
UK  delegation)  who  are  interested  in  the  use  of  CONS.  WGS  was  requested  to  support  the 
development  of  subnetwork  independent  CONS  protocols  and  associated  routing  protocol 
standards,  as  well  as  working  on  CLNS  standards  development  [Ref.  Messina  1993b] 

Another  proposal  for  new  work  (not  yet  incorporated  into  the  18-month  work  plan)  is  a 
LAN-to-X.25  relay.  Neither  NACISA  nor  Canada,  who  agreed  in  1992  to  investigate  availability 
of  resources  for  this  work,  have  found  resources  to  lead  such  an  effort  [Ref.  Messina  1993a] 

17.3.4  WG6  Activities  and  Plans  for  Upper  Layers  and  Pan-Layer  Issues 

17.3.4.1  WG6  Activities 

The  following  activities  have  been  reported  by  SG91WG6  participants. 

•  Preparing  STAN  AGs  for  final  comment  preceding  ratification:  4406  (message 
handling)  and  4407  (systems  management). 

•  Submitted  (May  1993)  STANAG  4250-3,  Naming  and  Addressing,  in  final  form  for 
ratification  (Ratification  is  underway  and  has  received  US  concurrence.)  [Ref. 
Curcio  1994] 

•  Submitted  (May  1993)  two  upper  layer  STANAGs  to  IMS  for  ratification  when 
translation  is  complete:  4257  and  4267. 

•  Developing  a  registration  document  on  Message  Handling  names.  Directory  names, 
and  managed  objects. 

•  Work  on  upper  layer  security.  Continuing  liaison  with  the  AHWG  on  Security  to  seek 
near-term  solutions  for  authentication  and  non-repudiation  with  regard  to  Directory 
service.  One  solution  is  the  use  of  asymmetric  encryption  tables. 

17.3.4.2  WG6  Work  on  MMHS 

The  AHWG  on  MMHS  continues  liaison  with  developers  of  Allied  Communications 
Publication  (ACP)  123  and  harmonization  with  STANAG  4406.  A  separate  annex  (Annex  D)  of 
STANAG  4406  specifies  the  ACP  127  gateway  (no  provision  has  yet  been  made  for  an  ACP  123 
gateway). 

MMHS  will  be  addressed  in  a  separate  Application  Layer  standard,  STANAG  4406  [Ref. 
STANAG  4406  1991]  (September  1991;  see  Section  17.4.2).  STANAG  4406  will  incorporate 
four  elements  that  are  being  developed  simultaneously  by  the  AHWG  on  MMHS:  Base  Standard, 
Rationale,  an  Alpha  Profile,  and  a  Beta  Profile.  The  Alpha  profile  is  intended  to  address  strategic 
and  tactical  applications  where  bandwidth  limitations  are  not  severe,  and  the  Beta  Profile  is 
intended  to  address  tactical  applications  where  bandwidth  is  severely  limited.  For  the  Beta  profile, 
the  AHWG  on  MMHS  assumes  that  bandwidth  will  be  conserved  by  eliminating  all  but  the  most 
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vital  services  of  MHS.  These  profiles  are  being  written  as  a  "delta"  or  change  to  the  MHS  profile 
being  developed  by  the  European  Workshop  for  Open  Systems  (EWOS)  [Ref.  EWOS  1990a]. 
Each  MMHS  profile  will  be  included  in  STAN  AG  4406  as  a  separately  ratifiable  annex.  [Ref. 
SG9/WG1  1990c] 

The  AHWG-MMHS  work  has  been  separated  into  two  sets  of  functional  groups.  The  first 
set  consist  of  military  messaging  services,  notification,  security,  redirection,  distribution  lists, 
conversion,  ACP  127,  and  MMHS  gateways.  The  second  set  will  provide  directories,  current 
draft  of  STANAG  4406  addresses  the  first  set  of  functional  groups.  [Ref.  Krick  1991] 

The  Intercept  Profile  for  MMHS,  based  on  MHS: 1984,  has  been  amended  (Issue  2)  to 
include  full  support  for  ACP  127  [Ref.  MMHS  1990].  It  was  completed  in  February  1990. 
Issue  2  has  a  new  annex  (Annex  C)  on  implementation  options  for  the  military  header  extensions. 
Issue  1  of  the  profile  was  accepted  as  an  intercept  strategy  for  the  NTIS  Transition  Strategy  [Ref. 
NATO  1991];  however,  depending  on  choices  of  interoperability  parameters,  MMHS 
implementations  based  on  MHS:  1988  may  not  be  backwards  compatible  with  MHS:  1984 
implementations.  Only  MHS:  1988  is  in  the  NOSIP  Strategy. 

One  area  of  MMHS  not  addressed  by  MHS:  1988  is  support  for  trusted  functionality.  Such 
support  may  be  covered  by  the  NLSP,  TLSP,  and  TCS  to  carry  out  services  associated  with 
trusted  functionality.  The  May  1989  meeting  of  the  AHWG-MMHS  was  devoted  to  security  and 
succeeded  in  developing  two  functional  groups  of  security  services.  One  of  these  does  not  require 
use  of  asymmetric  encipherment  mechanisms,  but  precludes  direct  support  of  non-repudiation 
services.  These  have  both  been  accepted  by  EWOS.  The  AHWG-MMHS  sought  guidance  from 
the  AHWG  on  Security  to  identify  suitable  encipherment  mechanisms  to  support  these  services. 
[Ref.  SG9/WG2  1989]  The  AHWG  on  Security  confirmed  the  need  for  asymmetric  cryptographic 
mechanisms  and  indicates  that  such  mechanisms  need  to  be  offered  by  the  Nations  for 
consideration  and  approval  by  the  appropriate  NATO  authorities.  [Ref.  AHWG-S  1990a] 

17.3.5  AHWG  on  Security*9 

17.3.5.1  Activities  of  AHWG  on  Security 

The  AHWG  on  Security  has  been  working  almost  exclusively  on  developing  a  security 
protocol  for  the  Network  Layer  of  the  OSI  Reference  Model.  The  goal  was  to  define  a  security 
protocol  specification  and  service  definition  that  would  be  a  subset  of  whatever  was  adopted  as  an 
international  standard.  This  effort  was  labeled  the  Trusted  Communications  Sublayer  (TCS). 

With  input  from  representatives  of  the  AHWG  on  Security,  the  JTC1/SC6/WG4  combined 
three  security  protocols  into  the  Network  Layer  Security  Protocol  (NLSP).  They  were  the  US 
SDNS  SP3,  Northern  Telecom's  SPX,  and  the  UK's  End-to-End  Security  Protocol  (EESP). 
NLSP  reached  IS  status  at  the  September  1993  meeting  of  SC6  in  Seoul  (ISO/IEC  11577, 
October  1993). 

Final  editing  of  the  TCS  Protocol  Specification  and  Service  Definition  by  the  AHWG  on 
Security  will  make  it  possible  to  describe  the  TCS  as  a  profile  of  ISO/IEC  1 1577  (NLSP)  with 
some  local  procedure  extensions.  These  local  procedure  extensions  to  NLSP  are  only  necessary  in 
the  connection-oriented  mode  of  operation,  since  there  are  no  fundamental  differences  between  the 
TCS  and  NLSP  in  the  connectionless  mode  of  operation. 


19  Based  00  the  following  sources:  [Staton  1994],  [McLsne  1993a],  and  [McLane  1993b). 
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The  AHWG  on  Security  has  developed  three  major  references  for  use  in  SG9:  NATO  OSI 
Security  Architecture  (NOSA)  [Ref.  NOSA  1988],  Security  Architecture  for  NATO  Information 
Systems  Interconnection  (SANISI)  [Ref.  SANISI  1989],  and  the  NATO  Network  Security 
Information  Classification  Guideline.  NOSA  was  developed  as  an  unclassified  document  to  give 
guidance  to  contractors  and  procurement  managers  on  the  preferred  placement  of  security  services 
within  OSI  conformant  systems.  SANISI  provided  more  detailed  rationale  on  the  placement  of 
security  services  and  mechanisms  with  the  OSI  Reference  Model.  A  key  element  of  both  NOSA 
and  SANISI  was  the  requirement  for  a  TCS  security  service  at  Layer  3.  No  security  services  were 
identified  for  Layer  4,  the  Transport  Layer.  The  final  NOSA  document  is  Version  3.1,  dated 
September  1988,  and  the  final  SANISI  document  is  Version  2.0,  dated  April  1989.  Additional 
documents  to  support  the  TCS  are  the  TCS  Applications  Guidelines  that  define  the  placement  and 
operation  of  the  TCS  within  both  connectionless  and  connection-oriented  modes  of  operation,  the 
TCS  Service  Definition  (Annex  B  of  STANAG  4253),  and  the  TCS  Protocol  Specification 
(Annex  B  of  STANAG  4263).  These  documents  are  expected  to  become  stable  in  early  1994. 

Work  has  begun  on  Part  2  ( Security )  of  STANAG  4250  to  make  it  the  appropriate 
reference  document  incorporating  the  pertinent  parts  of  SANISI  and  NOSA.  The  NATO  security 
architecture  for  voice  and  video  communications  is  currently  under  development  and  is  expected  to 
be  included  in  a  supplement  to  this  STANAG. 

17.3.5.2  Work  Plan  of  AHWG  on  Security 

The  1 8-month  work  plan  is  being  revised  by  the  AHWG  on  Security;  it  will  address  the 
deliverable  documents  related  to  the  TCS,  management,  and  upper  layer  issues.  Table  54  identifies 
the  specific  tasks  given  to  the  AHWG  on  Security  in  the  revised  special  tasking  instructions. 

Table  54.  Plannad  Activities  for  AHWG  on  Security 
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number  of  scenarios  are  being  discussed,  some  outside  the 
ISDN  domain  (e.g.,  in  the  tactical  area)  and  some  within  the  strategic  ISDN  domain  (e.g.,  as  user  moving 
from  one  PABX  to  another).  Only  strategic  ISDN  domain  issues  are  currently  being  addressed  in  the 
AHWG  on  ISDN.  It  was  agreed  that  ISDN  SuspencyResums  procedures  for  moving  during  a  cat  were  not 
applicable  to  mobile  hosts.  Some  form  of  slow  mobility  is  required  where  a  user  may,  for  example,  move 
between  extensions  on  the  same  access  switch  or  even  to  a  different  access  switch  and  still  maintain  the 
same  user  identify.  This  would  require  a  type  of  registration  and  cancellation  procedure  where  a  user  takes 
the  user  identity  around  a  fixed  network.  Specific  NATO  procedures  may  be  required  to  realize  this 
feature— further  study  is  required.  Procedures  associated  with  the  cellular  radio  service  are  issues  mainly 
applicable  to  the  tactical  domain. 

(2)  Multi-Endpoint  Connections.  Information  needs  to  be  multicast  (or  broadcast)  to  several  destinations.  A 
central  issue  is  whether  a  unidirectional  service  was  required  for  this  feature: 

(a)  If  the  requirement  were  defined  in  terms  of  a  conference  call  (bidirectional),  then  commercial  products 
are  expected  to  be  available. 

(b)  If  broadcast  facilities  were  provided  at  the  Application  Layer  using  packet  procedures,  no  specific 
NATO  procedures  are  required. 

(c)  If  broadcasting  were  required  on  all  bearer  services  (e.g.,  voice  and  data),  then  the  AHWG  on  ISDN 
should  wait  for  ITU-TS/ETSI  to  define  this  feature. 

It  was  generally  agreed  that  the  multi-endpoint  feature  is  for  data  application  rather  than  voice;  further 
study  is  required  on  the  requirement  for  voice. 

(3)  Internetworking.  The  NATO  C3  Architecture  (Volume  4,  Communications  Subsystenri)  a  Hows  both  the  *T* 
reference  point  and  the  K,  M,  and  N  reference  points  as  possibilities  for  internetworking.  If  the  *T 
reference  point  were  chosen,  then  a  number  of  enhancements  would  be  required  for  NATO,  such  as 
satellite  and  routing  indicators. 

(4)  Network  and  System  Management.  ITU-TS  is  defining  a  network  management  structure  in  both  the  user- 
network  area  (Q.940)  and  within  the  network.  This  work  is  at  the  architectural  level  and  has  not  resulted  in 
a  definition  of  detailed  procedures.  Of  particular  interest  to  SG9  are  the  management  functions  of 
Section  3  of  Q.940  for  fault,  configuration,  accounting,  performance,  and  security  management— ell 
aligned  with  OSI  management  functions.  In  addition,  management  reference  models  have  been  defined. 

(5)  Security.  Key  issues  are  the  applicability  of  the  TCS  to  ISDN  (for  data  services),  the  impact  e*  ISDN  on  the 
security  services  defined  in  STANAG  4250^2  (Part  2):  Security,  and  the  definition  of  new  security  features 
using  ISDN  capabilities  (e.g.,  common  channel  signaling). 

(6)  Robustness  and  Quality  of  Service.  The  only  posable  special  NATO  requirement  identified  is  the  QoS 
parameter,  should  the  ISDN  network  performance  figures  given  in  1.350  not  prove  to  be  adequate  for 
military  applications. 

(7)  Precedence  and  Preemption.  This  feature  is  already  being  addressed  (service  definition  and  information). 

(8)  Real-Time  and  Tactical  Communications.  No  special  real-time  requirements  are  foreseen  for  ISDN.  Note 
that  the  discussion  was  limited  to  interworking  with  a  tactical  network  and  to  the  concept  of  a  strategic 
ISDN  activity  either  as  a  transit  network  or  to  gain  access  to  an  ISDN  user. 


Source:  Report  of  the  2nd  Ad  Hoc  Meeting  on  ISDN  in  Paris,  April  1990,  TSGCE  SG9  AHWG  on  ISDN.  May  1990, 
NATO  UNCLASSIFIED. 

Note:  The  suitability  of  the  ISDN  protocols  for  use  in  the  tactical  domain  was  agreed  to  be  outside  the  ecope  of 
the  aesessment  leading  to  these  requirements. 

One  of  the  issues  for  discussion  within  the  AHWG  on  ISDN  has  been  the  alternative 
facsimile  (FAX)  standards  for  ISDN:  G3  (64  kbps)  versus  G4. 

17.3.7  PG9  on  MIDS  LVT 

PG9  on  the  MIDS  Low  Volume  Terminal  (LVT)  was  formed  by  TSGCE  to  develop  an 
MOU  for  an  multinational,  multi- Service,  cooperative  program  for  a  light-weight  tactical 
information  distribution  system.  (PG9  was  disbanded  at  the  end  of  1992,  and  a  NATO  Project 
Steering  Committee  was  established  under  the  terms  of  an  MOU.) 

The  LVT  would  be  a  pre-planned  product  improvement  to  the  Joint  Tactical  Information 
Distribution  System  (JTIDS)  that  would  reduce  the  size  (from  1.7  to  0.6  cu  ft)  and  weight  (from 
135  lb  to  65  lb).  The  LVT  would  reuse  the  JTIDS  software,  including  the  LINK  16  (JTIDS) 
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standard  (and  not  IJMS).  The  participating  nations91  (FR,  SP,  IT,  GE,  and  US)  plan  ground- 
based,  airborne,  and  ship-based  employment  (the  US  would  use  it  for  the  F/A-18s).  The  project 
definition  phase  (1987-1990)  was  followed  by  the  pie-engineering  and  manufacturing  development 
(EMD)  phase  (1991-1992),  in  which  the  request  for  proposal  (RFP)  was  finalized  and  released, 
proposals  evaluated,  and  contracts  negotiated.  National  contractors  are  expected  to  be  awarded 
work  at  the  same  proportion  as  national  funding.  The  EMD  phase  (1992-1997)  began  with 
contract  award  and  includes  design,  fabrication,  integration,  test,  and  technical  data  package 
verification.  The  production  phase  (1997-2010)  is  initially  planned  to  acquire  2,750  LVTs  (plus 
spares).  [Ref.  TSGCE  1991gJ 

17.4  Status  of  NATO  Open  System  STANAGs 

17.4.1  OSI  Layer  STANAGs 

Table  56  identifies  the  STANAGs  being  developed  that  will  specify  ISO  standards  and 
applicable  military  options  and  extensions,  if  any.  Work  has  begun  on  all  these  STANAGs,  but 
only  the  NATO  Reference  Model,  STANAG  4250,  has  been  ratified.  Originally,  TSGCE  SG9 
planned  to  issue  a  single  STANAG  for  all  services  and  a  second  STANAG  for  all  protocols  at  each 
layer,  giving  a  total  of  14  STANAGs  in  addition  to  STANAG  4250,  the  NATO  Reference  Model. 
In  October  1987.  TSGCE  SG9  agreed  [Ref.  UK  1988,  Annex  1.2]  to  work  at  the  Application 
Layer  for  single  STANAGs  for  each  Application  Layer  service,  such  as  MMHS  (STANAG  4406). 
Protocol  specifications  as  well  as  service  definitions  would  be  addressed  in  that  STANAG. 

Little  progress  on  the  lower  layer  STANAGs  has  been  made  during  the  past  2  years.  Most 
of  the  changes  observed  on  the  various  drafts  of  these  documents  during  this  period  have  been 
editorial.  In  a  few  cases,  some  PICS  proformas  have  been  added.  Since  these  documents,  for  the 
most  part,  adopt  international  standards  without  enhancements,  it  is  not  clear  why  these  standards 
were  not  released  for  ratification  in  1991.  The  need  for  the  layer  STANAGs  is  not  clear,  especially 
if  their  primary  role  is  to  provide  cover  sheets  for  international  civil  standards. 

17.4.2  Application  and  Multi-Layer  STANAGs 

The  only  Application  Layer  STANAG  that  has  been  produced  in  draft  form  is  the  draft 
MMHS  STANAG  4406.  The  parts  of  this  standard  are  as  follows: 

•  Annex  A — MMHS  Extensions  to  ISO  10021  Series,  Draft 

•  Annex  B — Security  Aspects  of  MMHS  (under  development) 

•  AnnexC — Alpha  Profile  Set  (a  delta  specification  to  EWOS  profiles):  AMHlx(M)  on 
Common  Facilities  and  AMH9x(M)  on  Military  Messaging,  Draft 

•  Annex  D — Alpha/ ACP  127  Gateway  (under  development) 

•  Annex  E — Alpha/MMHS(84)  Gateway  (under  development) 

•  Annex  F — Alpha/MHS(88)  Gateway  (under  development) 

•  Annex  G — Beta  Profile  Set  (under  development) 

•  Annex  H — Beta/ACP  127  Gateway  (under  development) 

•  Annex  I — Beta/ Alpha  Gateway  (under  development). 


9 1  Norway,  Canada,  and  the  United  Kingdom  participated  in  the  project  definition  phase  but  declined  to  continue 

into  development  and  procurement. 
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TaM*  86.  NATO  081  Standard* 


Halation 

Sarviea  Definitions 

Protocol  Spoclfieatlone 

to  OSI 

STANAG 

Statue 

Dee.  Data 

STANAG 

Statue 

Doc.  Date 

■■■■■ 

4250,4250-1 

Ratified 

21  August  1900 

NfA 

4250-2 

Staffing 

December  1993 

NfA 

4250-3 

Draft 

21  March  1993 

N/A 

4260-4 

Draft 

26  April  1993 

N/A 

4250-5X 

Canceled 

1992 

N/A 

4260-6X 

fanrrhrl 

1992 

N/A 

42S0-5Y 

re - n_^j 

VHCHN 

October  1993 

N/A 

4251 

Staffing 

30  April  1993 

4261 

17  March  1993 

4252 

Staffing 

26Maich1993 

4262 

18  March  1993 

■esoi 

4253 

Draft 

18  March  1993 

4263 

Draft 

19  March  1993 

Layer  4 

4254 

19  March  1993 

4264 

19  March  1993 

Layers 

4255 

Ratified 

S^F'"i*V.VTT"'^M 

4265 

Ratified 

V,T 

425S 

Ratified 

22  January  1993 

4266 

Ratified 

22  January  1993 

Layers 

4258  (ASN.1) 

Ratified 

22  January  1993 

4259  (ASN.1 
BER) 

Ratified 

22  January  1993 

Layer  7 

4257 

November  1993 

4267 

■--.1  i.'i'-N 

NOVWTMr  1W3 

■»  v  vm 

g;v-fi.TT' 

Draft 

November  1993 

N/A 

Profile 

gfi.yjiT.fTM 

Draft 

15  May  1993 

N/A 

re — ai. 

itotiw 

OHH 

Draft 

October  1993 

N/A 

re — «»- 
1 T0V1N 

iSuSHl 

Draft 

7  April  1993 

N/A 

re — ait— 

ITOTIW 

K SSS33)* 

Draft 

7  April  1999 

N/A 

Profile 

Draft 

January  1993 

N/A 

Note:  Staffing  imam  that  a  final  draft  ha*  beenaubmftted  by  Subgroup  9  to  the  NATO  International  MStary  SMI  for 
translation  and  (attribution  to  tha  nations  for  ratification. 

Source:  [Rannsstad  1994]. 


The  initial  draft  STANAG  4406  will  be  circulated  for  ratification  with  die  Military  Base 
Standard  (Annex  A)  and  the  ALPHA  Profile  Set  (Annex  C).  Annex  A  provides  the  set  of 
extensions  to  civilian  message  handling  systems  for  Interpersonal  Messaging  Service  (IPMS) 
required  for  military  messaging.  Annex  A  is  also  known  as  die  Military  Base  Standard. 

Table  57  identifies  the  military  features  as  they  affect  MMHS.  Previous  editions  of  the 
MMHS  draft  STANAG  have  included  additional  material  on  Scenarios  and  Rationale,  which 
provided  detailed  specification  of  the  scenario  of  application,  rationales  behind  die  major  decisions, 
and  discussion  of  the  support  of  the  subset  of  the  eight  military  features  that  are  applicable  to  a 
store-and-forward  messaging  environment.  This  document  is  now  being  prepared  separately.  The 
intent  is  to  have  an  excerpt  from  this  document  included  in  the  1991  edition  of  the  MMHS 
STANAG.  but  this  has  not  yet  been  done.  [Ref.  TSGCE  1991hJ 
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Table  57.  Status  of  X.400(MHS)-198e  Relative  to  the  Eight  Military  Features 


(a)  Multihoming  applies  to  MMHS  applications  in  two  ways:  multihoming  User  Agents  (UAs)  and 
multihoming  MTAs.  In  the  first  case,  the  MHS  must  allow  a  single  user  to  have  more  than  one 
Originator/Redpient  (CVR)  name.  The  second  case  requires  MTAs  that  answer  to  more  than  one  name.  In 
both  cases,  the  capability  in  question  is  outside  the  scope  of  the  communications  standards,  but  is 
permitted  as  an  implementation  option.  Capabilities  for  multihoming  would  have  no  direct  impact  on  either 
MHS  sendees  or  protocols,  but  are  instead  more  focused  on  the  lower  layers. 

(b)  Similarly,  mobile  hosting  can  also  be  applied  to  either  the  MTA  or  UA.  In  either  case,  the  key 
requirement  to  support  mobile  hosting  is  the  capability  for  the  functional  object  in  question  to  disconnect 
from  the  network  for  a  period  of  time  without  serious  consequence.  In  MMHS  there  are  two  mechanisms  to 
support  mobile  hosting  of  the  UA.  One  such  mechanism  is  the  use  of  a  message  store  (MS)  to  act  on  the 
UA's  behalf  while  the  UA  is  off  tine.  The  second  mechanism  is  use  of  the  Hold  for  Delivery  element  of 
service,  in  which  the  service  element  instructs  the  MTS  to  defer  delivery  of  a  UA's  messages  until  a  later 
time.  No  such  mechanisms  are  avalable  to  the  MTA,  however. 

Since  MHS  applications  are  store  and  forward  (i.e.,  connectionless)  in  nature,  no  end-to-end  connections 
are  provided  or  required  by  MMHS.  However,  the  MMHS  does  provide  a  connectionless  MPDT  capability  in 
the  form  of  multi-addressed  messages.  This  feature  allows  a  single  message  to  be  sent  to  several 
recipients  with  a  single  submission  to  the  MTS.  The  MTS  is  then  responsible  for  performing  traffic  splitting 
at  the  appropriate  time.  Note  that  traffic  splitting  could  be  substantially  more  efficient  H  supported  by  a 
lower  layer  MPDT  function 


Internetworking  is  addressed  by  the  provision  of  MMHS/ACP  127  and  MMHS/civilian  gateway  definitions. 
Gateways  could  also  be  created  to  other  systems  that  perform  similar  message  handling  functions,  but 
such  gateways  are  at  present  beyond  the  scope  of  MMHS. 

Network  and System  Management 

Network  management  is  a  pan-layer  issue  that  fals  under  the  auspices  of  the  AHWG-OM  in  SG9.  The 
AHWG-MMHS  will  continue  to  identify  MHS-related  topics  to  be  considered  by  AHW6-OM. 

Security 

Security  is  a  pan-layer  issue  that  falls  under  the  auspices  of  the  AHWG  on  Security  in  SG9.  The  AHWG- 
MMHS  wM  continue  to  identify  MHS-related  topics  to  be  considered  by  the  Security  AHWG. 


Most  aspects  normally  associated  with  robustness  and  QoS  have  no  meaning  in  the  AppBcation  Layer. 
Three  MHS  characteristics  have  been  identified  as  significant  in  terms  of  robustness  and  QoS:  loss  of 
massages,  end-to-end  delivery  time  requirements,  and  selection  of  security  services.  QoS  aspects 
relating  to  Ink  quality,  hop-by-hop  transmission  delay,  and  throughput  are  primarfly  lower  layer  issues,  and 
in  any  case  have  little  meaning  for  a  ft  ore-  and-f orwa  rd  Application  Layer  process. 

(a)  Loss  of  message  is  addressed  by  the  MMHS  expansion  of  X.400's  redirection  capability.  This 
provides  a  dead  letter  box  at  each  MTA  so  that  messages  wil  always  be  delivered  rather  than  discarded. 
MMHS  also  provides  both  delivery  and  nondelivery  receipt  capability  to  provide  additional  assurance  of 


(b)  MMHS  has  specified  end-to-end  delivery  time  requirements  consistent  with  those  used  by  ACP  127. 
The  hop-by-hop  transmission  delay  and  throughput  necessary  to  achieve  those 
end-to-end  times  are  lower  layer  issues. 

(c)  Selection  of  appropriate  security  services  is  largely  dependent  on  the  security  policy  in  force.  This 
policy  will  determine  what  services  wiH  be  enabled  during  the  origination  of  a  message  based  on  its 
classification  or  other  factors.  This  selection  could  be  done  either  technicaly  or  procedural,  however, 
and  thus  Is  purely  an  implementation  issue.  Whatever  solution  is  used  wil  impact  only  the  originator  and 
wM  not  require  changes  to  the  communication  protocols. 

(7)  Pitctdtnse  md  Prttnrtott 

The  established  requirement  for  military  priority  in  message  handing  is  four  levels  based  on  ACP  127.  The 
MMHS  base  standard  provides  six  priority  levels  in  all  protocols  necessary  to  support  the  use  of 
precedence  and  preemption  in  any  implementation.  However,  it  is  the  intent  of  the  AHWG-MMHS  to 
develop  functional  profies  that  support  six  levels  of  priority  in  the  UA-to-UA  protocols  but  only  three  levels 
in  the  corresponding  MTA-to-MTA  protocols.  Use  of  these  provided  information  elements  to  support 
precedence  and  preemption  in  either  the  UA  or  MTA  is  an  implementation  issue. 

(8)  Tactical  and  RtUlmi  CommunicMion* 

MMHS  has  specified  end-to-end  delivery  time  requirements  that  are  purported  to  represent  the  tactical 
environment.  In  addition,  the  AHWG-MMHS  plans  the  development  of  a  Safe  Profift  tailored  to  low 
bandwidth  tactical  applications. 


Source:  Draft  STANAG  on  Military  Maaaaga  Handling  Syatam,  February  1990,  NATO  UNCLASSIFIED. 
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17.4.3  NATO  Standardised  Profile  (NSP)  STANAGs 
The  work  of  TSGCE  SG9  in  1993  has  focused  on  development  of  NATO  Standardised 
Profiles  (NSPs).  Table  58  identifies  the  drafts  under  development 

Table  58.  Statue  of  NATO  Standardized  Profile* 


STANAG  4406,  NATO  Standardize  PraHe  •  Connection-mode  Transport  Serves  over  Connectionlsst  mod* 
Network  Service,  Draft  (in  final  editing  prior  to  translation  for  ratification),  October  1083,  NATO 
UNCLASSIFIED 

Parti:  Subnetwork  Type  Independent  Requirements  for  Group  TA.  PreNminary  Draft  (cf.  IS0 10606-1) 

Pert  2:  TA5n(M)  Subnetwork  Type  Dependent,  Media  Independent  Requirements  for  LANs,  PreNmlnaiy 
Draft  (cf.  IS0 10606-2) 

Part  3:  TA51(M)  Subnetwork  Typo  Dependent,  Medw  Independent  Requirements  for  CSMA/CD  LANs. 
PreNminary  Draft  (cf.  IS0 10608-2) 

Part  4:  TA54(M)  Subnetwork  Type  Dependent  Media  Independent  Requirements  for  FDDI  LANs, 
PreNminary  Draft  (cf.  IS0 10606-6) 

STANAG  4400,  NATO  Standardized  Profile  •  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service  (Military),  Draft  (in  final  editing  prior  to  translation  for  ratification),  7  April  1003,  NATO 
UNCLASSIFIED 

Parti:  DeflnWonof  ProfNee  TC1 11 1(MyTCl121  (M).  PreNminary  Draft  (cf.  IS0 10600-6) 

Pert  2:  Subnetwork  Type  Independent  Requirements  for  Group  TC,  PreNmineiy  Draft  (cf.  IS0 10608-2) 

Part  3:  TA51(M)  Subnetwork  Typo  Dependent  Requirements  for  Permanent  Access  to  a  Packet  Data 
Network  Using  Virtual  Call,  PreNminary  Draft  (cf.  IS0 1 0608-8) 

STANAG  4410,  NATO  Standardized  Profile  -  Connectionless-mode  Transport  Sendee  over  Connectionless  mode 
Network  Service,  Draft,  7  April  1083,  NATO  UNCLASSIFIED 
Part  1:  Subnetwork  Type  Independent  Requirements  for  Group  UA.  Preliminary  Draft 
STANAG  441%  NATO  Stenderdteed  ProHe  -  Relaying  the  Connectionless-mode  Network  Service 

Part  1:  Subnetwork  Typo  Independent  Requirements  for  Group  RA,  Edition  2.  January  1883  (cf. 
IS0 10613-1)  (under  development) 

Part  2:  Subnetwork  Type  Dependent  Msdtai  Independent  Requirements  for  LANs,  EdMon  2.  January  1993 
(cf.  IS0 10613-2)  (under  development) 

Part  3:  ISDN  Subnetwork  Dependent,  MetSa  Dependent  Requirements  for  CkcuN  Swtched  B-Channel 
Operation,  EdMon  2,  January  1983  (under  development) 

Pert  4:  ProfNa  RA51.4212.  EdMon  2.  January  1910  (under  development) 


17.4.4  ISDN  STANAGs 

The  following  draft  STANAGs  are  being  developed  for  ISDN  services: 

•  STANAG  4459,  ISDN  Bearer  Services,  Draft  (in  final  approval  prior  to  submission 
for  translation  and  ratification),  1 1  May  1993  (cf.  L230) 

•  STANAG  4460,  Layer  1  Specifications  for  ISDN  Basic  Rate  Access  at  the  S/T 
Reference  Point,  Draft  (in  final  approval  prior  to  submission  for  translation  and 
ratification),  11  May  1993 

•  STANAG  4461,  Layer  I  Specifications  for  ISDN  Primary  Rate  Access  at  ihe  S/T 
Reference  Point,  Draft  (in  final  approval  prior  to  submission  for  translation  and 
ratification),  11  May  1993 

•  STANAG  4462,  Layer  2  Specifications  for  ISDN  Basic  and  Primary  Rate  Access  at 
the  S/T  Reference  Point,  Draft  (in  final  approval  prior  to  submission  for  translation 
and  ratification),  11  May  1993 

•  STANAG  4463,  Layer  3  User  to  Network  Call  Control,  Preliminary  Draft, 
8  April  1993 

•  STANAG  4464,  Signalling  System  No.  7  Message  Transfer  Part  ( MTP )  (under 
development) 
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•  STANAG  4465.  Signalling  System  No.  7  ISDN  User  Part  (ISUP)  (under 
development) 

•  STANAG  4466,  ISDN  Teleservices  (under  development) 

•  STANAG  4467.  ISDN  Supplementary  Services  (wider  development) 

•  STANAG  4468.  QSIG  (under  development). 

17.5  Development  of  Other  Technical  STANAGs 

This  section  identifies  non-OSI  STANAGs  that  appear  to  be  relevant  to  information 
systems.  Media-dependent  STANAGs  (e.g.,  tactical  data  links)  are  not  addressed. 

17.5.1  Media-Independent  Data  Link  Architecture  (MIDLA) 

MIDLA  was  suggested  to  TSGCE  by  ADSIA  in  1986  [Ref.  ADSIA  1986].  During  the 
period  1987-1989,  die  Nations  attempted  to  identify  Nunn  Initiative  funding  for  MIDLA,  but  these 
efforts  were  unsuccessful  At  the  October  1989  SG9  plenary  meeting  [Ref.  TSGCE  1989],  the 
Nations  agreed  that  development  of  a  data  link  architecture  based  on  the  OSI  Reference  Model  to 
replace  antiquated  data  links  was  extremely  important  However,  it  was  also  agreed  that  resources 
were  not  available  within  SG9  to  address  the  breadth,  complexity,  and  technical  aspects  of  that 
subject.  SG9  agreed  to  send  a  letter  to  TSGCE  stating  die  importance  and  magnitude  of  this 
project  In  addition,  the  Nations  were  asked  to  reassess  the  availability  of  resources  relative  to  the 
MIDLA  project 

MIDLA  is  one  of  the  topics  suggested  for  discussion  in  the  newly  created  WG4  on  Data 
Links.  However,  it  is  not  an  item  of  current  interest  to  that  group  (see  Section  17.3.2).  A  bilateral 
agreement  has  been  established  between  France  and  the  United  Kingdom  regarding  future  data  link 
architectures.  At  the  September  1991  meeting  of  WG4,  France  indicated  that  MIDLA  development 
has  not  progresaed  sufficiently  for  it  to  be  brought  into  the  SG9  forum.  [Ref.  Ahem  1991] 

Further,  ADSIA  has  received  an  STC  study.  An  Architecture  Based  on  OSI  Principles  for 
NATO  Tactical  Data  Links  [Ref.  SHAPE  1989],  and  has  indicated  to  TSGCE  SG9  that  no  further 
work  on  behalf  of  ADSIA  is  required  for  MIDLA  [Ref.  ADSIA  1990]  However,  tactical  data 
link  architecture  is  being  addressed  by  the  TSGCE  AHWG  on  Restructuring  as  a  potential  area  of 
work.  SG9  has  indicated  that  if  the  SG9  terms  of  reference  are  amended  to  include  tactical  links, 
guidance  from  the  TSGCE  would  be  required  on  providing  necessary  resources.  [Ref.  TSGCE 
1990k,  TSGCE  1990b] 

17.5.2  Network  Independent  Interface  (NIIF) 

NIAG  SG6  is  developing  a  draft  specification  of  a  Network  Independent  Interface  (NIIF). 
This  was  briefed  to  the  TSGCE  SG9  AHWG-OM  in  February  1989.  NIIF  is  a  concept  for  a 
combat  system  data  distribution  interface  that  could  be  used  by  the  NATO  Frigate  Replacement  for 
the  1990s  (NFR90),  a  program  currently  in  a  project  definition  phase. 

In  a  subsequent  joint  meeting  with  die  NIAG  SG6  and  TSGCE  SG9/WG1  in  June  1989 
[Ref.  NIIF  1989],  die  NIIF  was  identified  as  a  project  to  (1)  put  NACISA  in  the  lead  Xr  resolve 
interface  problems  and  provide  management  structure  for  such  projects;  (2)  provide  near-  and  mid¬ 
term  standards  specification  for  ACCIS  interoperability;  (3)  initially  develop  interface  specifications 
to  pass  character-oriented  messages  between  existing  systems;  and  (4)  evolve  the  specification  so 
dud  it  will  be  suitable  for  other  services  (e.g..  Hie  transfer,  virtual  terminal).  The  specifications 
were  to  be  bared  on  ISO  OSI  standards  and  on  functional  profiles  of  SPAG  and  CEWCENELEC 
that  are  adopted  in  die  NTIS  Transition  Strategy :  T.21  Permanent  Circuit  (telephonic),  T.22 
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Switched  Circuit  (telephonic),  and  T.31  Permanent  Access  to  a  PSDN.  BID- 1000  and  KG-84 
were  identified  for  communications  security.  The  message  handling  area  was  based  on  A/321 1 
from  the  EWOS. 

As  early  as  September  1987,  NIAG  SG6  proposed  a  draft  STANAG  for  NATO  Naval 
Intra-Ship  Tactical  Control  and  Data  Handling  Open  Systems  Interconnection,  Network 
Independent  Interface,  Transport  Service  Definition  for  Connection-Mode  Transmission.  [Ref. 
NATO  1987a]  This  proposal  was  based  on  ISO  8072  with  "additions  and  deletions,  where 
necessary,  to  reflect  a  unique  Naval,  intraship,  interpretation  to  it"  The  NDF  is  identified  in  this 
proposal  as  a  collection  of  standards  that  provide  the  complete  definition  of  an  interface  between 
the  User  and  the  Data  Transfer  System,  based  on  unique  requirements  for  real-time,  fault  tolerant 
information  exchange  between  peer  systems. 

17.5.3  Lightweight  Protocols 

The  TSGCE  AHWG  on  Restructuring  has  noted  that  the  work  of  NIAG  SG6  is  closely 
related  to  the  work  of  TSGCE  SG9  on  OSI  standards.  Both  groups  are  interested  in  the  area  of 
lightweight  LAN  profiles  for  multi-Service  use.  The  basis  for  the  intraship  LAN  profile  being 
developed  by  NIAG  SG6  is  based  on  France's  GAM-T-103,  as  is  the  US  SAFENET  profile  and 
the  more  general  Xpress  Transfer  Protocol  (XTP)  profiles.  [Ref.  AHWG-OM  1990] 

The  XTP  is  a  lightweight  (providing  simplicity  and  low  overhead)  transfer  protocol  with 
unified  internetwork  services  associated  with  OSI  Layers  3  and  4.  XTP  conforms  to  the 
architecture  of  the  Transfer  Layer  in  RTFS  developed  in  France  for  use  in  LANs  (see  Section  5  of 
Appendix  J).  [Ref.  GAM  1987]  XTP  is  designed  to  support  100  Mbps  sustained  transfer  rates 
between  application  programs  with  growth  to  1  Gbps.  XTP  is  designed  to  provide  services  for 
distributed  systems  not  available  in  ISO  TP4  and  US  DoD  TCP;  the  requirements  include 
supporting  remote  procedure  calls  and  rapid  request/response  operations,  coordinating  multiple 
processes,  and  providing  transaction-based  file  access.  XTP  supports  traditional  stream  services, 
bulk  transport,  real-time  reliable  datagram  service,  real-time  internet  gateways,  flow/error/rate 
control,  message  delivery  confirmation,  selective  retransmission,  message  boundary  preservation, 
multiple  addressing  plans,  out-of-band  signalling,  reliable  multicast  mechanism,  maintenance 
packets,  and  multipath  capability.  [Ref.  XTP  1988,  XTP  1989] 

XTP  has  been  submitted  to  ANSI  X3S3  for  standardization  of  its  services.  Its 
standardization  is  also  being  progressed  in  the  US  Navy  SAFENET  Committee. 

17.5.4  EUROCOM  and  US/EUROCOM 

EUROCOM.  EUROCOM  is  a  technical  working  group  composed  of  representatives 
from  the  NATO  European  nations  whose  aim  is  to  achieve  better  coordination  and  interoperability 
in  tactical  communications  systems  between  European  Allied  armies.  EUROCOM  is  a  subgroup  of 
the  EUROGROUP,  an  informal  grouping  of  European  governments  within  the  framework  of 
NATO.  Rather  than  trying  to  agree  on  a  single  system,  it  is  EUROCOM's  plan  to  introduce 
communications  systems  in  accordance  with  agreed  operational  requirements  and  basic  system 
parameters  in  such  a  way  that  there  is  complete  interoperability  among  systems  built  to  EUROCOM 
standards.  EUROCOM  standards  are  frequently  offered  as  the  basis  for  NATO  STANAGs  on 
tactical  communications.  [Ref.  Manno  1989] 
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The  documents  (D)  currently  promulgated  by  EUROCOM  include: 

•  EUROCOM  D/0:  System  Concept,  CONFIDENTIAL  (date  of  last  revision  unknown) 

•  EUROCOM  D/1 :  Tactical  Communications  Systems  Basic  Parameters,  1986  (Revised 
September  1988),  RESTRICTED 

•  EUROCOM  D/2:  (title  and  date  unknown)  subject  is  testing. 

EUROCOM  systems  are  basically  circuit-switched  time  division  multiplexing  (TDM) 
systems,  with  a  basic  channel  rate  of  16  kbps  and  delta  [continuously  variable  slope  delta  (CVSD)] 
modulated  voice  transmission.  Combinations  of  these  channels  are  used  to  offer  32-kbps  circuits 
and  256-kbps  and  512-kbps  trunks.  Circuit-switched  connections  usually  operate  at  0.0S,  2.4,  or 
9.6  kbps.  An  option  is  available  for  a  packet  switched  data  service.  A  set  of  Enhanced 
EUROCOM  Standards  (EESs)  is  being  established,  with  a  planned  completion  in  1994.  These 
standards  will  address  packet  radio,  message  handling,  and  video.  Among  proposals  being 
considered  is  variable-bit-rate  transmission  using  a  flexible  forward  error  correction  (FEC) 
scheme,  enabling  ATM  to  be  used  over  noisy  media  such  as  radio  transmission.  [Ref. 
Valuer  1993] 

US/EUROCOM.  US/EUROCOM  is  an  informal  tactical  communications  technical 
working  group  comprising  die  EUROCOM  nations  and  the  United  States,  Canada,  and  France. 
The  purpose  of  US/EUROCOM  is  to  work  toward  better  and  less  cumbersome  interface 
arrangements,  to  monitor  the  implementation  agreements  on  communications  characteristics,  and  to 
promote  cooperation  in  the  procurement  of  equipment  conforming  to  these  characteristics.  Much 
of  die  preliminary  technical  work  leading  to  ratified  standardization  agreements  is  accomplished  by 
this  group. 

With  respect  to  work  in  OSI,  the  principal  interest  in  US/EUROCOM  is  with  the  lower 
three  layers.  Cunendy,  US/EUROCOM  is  in  the  process  of  modifying  STANAG  4249,  The 
NATO  Multi-Channel  Tactical  Digital  Gateway— Data  Transmission  Standards  ( Packet  Switching 
Service),  to  reflect  the  1988  version  of  ITU-TS  Recommendation  X.7S.  US/EUROCOM  is  also 
investigating  the  application  of  the  PICS-type  proformas  to  die  NATO  multi-channel  tactical  digital 
gateway  STANAGs.  [Ref.  Manno  1989] 

On  many  occasions  US/EUROCOM  has  accepted  invitations  from  TSGCE  to  work  on  the 
NATO  STANAGs  for  tactical  communications  (not  just  gateways)  and  interoperability  issues. 
US/EUROCOM  has  made  major  contributions  to  STANAGs  4206-4211  and  4350.  Both 
EUROCOM  and  US  military  standards  are  being  considered  for  drafts  of  STANAG  4290,  Fiber 
Optics.  In  each  case  die  technical  recommendations  from  US/EUROCOM  are  provided  to  TSGCE 
SGI  1  WG1  for  further  work,  coordination,  and  distribution  as  draft  STANAGs. 

The  work  of  US/EUROCOM  in  developing  a  profile  for  a  tactical  gateway  for  packet 
switching  (STANAG  4249)  was  briefed  to  die  TSGCE  SG9/WG1  in  the  October  1989  meetings  in 
Brussels.  In  addition,  Norway  provided  a  paper  that  suggested  US/EUROCOM  could  undertake 
several  tasks  of  interest  to  SG9.  These  include  proposing  PICS  proformas  for  the  STANAG 
4206-4214  series  (and  possibly  others,  such  as  STANAGs  4290  and  5040);  proposing  tactical 
parts  of  the  STANAG  4250  series;  identifying  profiles  required  by  the  tactical  communities  in 
NATO;  and  proposing  NATO  functional  profiles  for  tactical  applications.  However, 
US/EUROCOM's  role  in  developing  profiles  for  NATO  is  still  under  consideration  and  has  not 
been  fully  accepted  by  US/EUROCOM.  [Ref.  TSGCE  1991i] 
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17.5.5  Other  Efforts 

STANAG  4214,  International  Routing  and  Directory  for  Tactical  Communications,  may  be 
applicable  to  ATCCIS  technical  standards;  this  standard  is  the  responsibility  of  TSGCE  SG11. 
TSGCE  SG9/WG1  is  looking  at  naming  and  addressing  requirements  and  the  applicability  of 
STANAG  4214.  STANAG  4249,  The  NATO  Multichannel  Tactical  Digital  Gateway— Data 
Transmission  Standards  (Packet  Switching  Service),  also  the  responsibility  of  SGI  1,  addresses 
packet  switching  using  a  form  of  ITU-TS  X.25;  as  such,  this  STANAG  may  also  be  applicable  to 
ATCCIS  technical  standards.  The  EUROGROUP  on  Cooperation  of  Tactical  Communications 
Systems  (EUROCOM)  is  reported  to  be  preparing  a  revised  draft  for  STANAG  4249  based  on 
ITU-TS  X.25  and  the  draft  TSGCE  SG9  Functional  Profile  Guidelines  document;  such  a  draft 
would  be  submitted  to  SGI  1  as  a  contribution  and  developed  into  a  STANAG. 

17.6  Assessment 

a.  TSGCE  has  identified  and  assessed  eight  military  features  that  need  to  be 
incorporated  in  civil  OSI  standards,  but  little  detail  has  yet  been  released  (e.g.,  in  drafts  of 
STANAGs  4251-4266)  to  show  how  these  features  can  actually  be  addressed  in  military  versions 
of  OSI  standards.  There  does  not  seem  to  be  much  value  in  a  set  of  layer  STANAGs  that  primarily 
catalogue  ISO  and  ITU-TS  standards. 

b.  TSGCE  SG9  has  an  ambitious  18-month  plan  for  progressing  the  NATO  OSI  data 
communications  standards,  but  there  is  a  need  to  reassess  and  revalidate  the  military  features — 
clearly  the  deficiencies  of  1991  civil  standards  are  different  from  those  identified  in  1983.  For 
example,  great  progress  on  internetworking  has  been  made  in  ISO. 

c.  TSGCE  SG9  has  been  successful  in  many  areas  (such  as  security  and  OSI 
management)  for  introducing  military  work  into  the  civil  standards  bodies  and  affecting  the 
capabilities  of  the  civil  standards.  One  of  the  useful  approaches  being  taken  by  SG9  is  the  focus 
on  the  applicability  and  adequacy  of  civil  profiles  for  use  in  NATO  by  addressing  specific  military 
scenarios  and  groups  of  requirements.  Profile-oriented  work  is  essential  to  ensure  interoperability 
of  implementations  by  the  Nations.  It  is  clearly  the  focus  of  the  reorganization  of  SG9  that  will  be 
evolved  in  1992.  Current  efforts  on  profiles  need  to  be  supported  and  expanded.  This  work 
should  be  in  close  coordination  with  the  regional  implementor’s  workshops  (e.g.,  EWOS  and  the 
North  American  OIW),  since  NATO  cannot  afford  to  implement  on  a  wide  scale  major  variations 
of  the  profiles  negotiated  in  the  civil  communities. 
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18.  NEAR-TERM  ANALYSES,  INITIATIVES,  AND  SYSTEMS  FOR 

ACHIEVING  INTEROPERABILITY  IN  NATO 

TSGCE  is  developing  recommendations  and  standards  in 
two  areas,  in  addition  to  the  work  of  TSGCE  SG9  on  Data 
Distribution  (described  in  Chapter  17),  that  could  have 
significant  impact  for  information  systems.  These  are  SGI  1  on 
Communications  and  SG12  on  Information  Systems. 

Existing  and  emerging  ACCISs  are  designed  to  provide 
command  and  control  information  support  for  NATO  and 
national  systems.  Tire  ACE  ACCIS  will  provide  the  higher- 
echelon  support  (i.e.,  at  echelons  above  corps)  for  the  military 
forces  operating  in  the  European  region  of  NATO.  ATCCIS 
will  provide  support  for  land  combat  tactical  units,  and  the  Air 
Command  and  Control  System  (ACCS)  will  support  the  air 
operations. 

The  NATO  Maritime  Operational  Intelligence  Support 
(NMOS)  and  the  Battlefield  Information  Collection  and 
Exploitation  Systems  (BICES)  will  provide  intelligence  support 
Other  ACE  ACCIS  -related  projects  include  the  Standard 
Automated  Message  Interface  for  NATO's  ACCISs 
(STAMINA),  JRMS,  die  Status  Control  Alerting  and  Reporting 
System  n  (SCARS  II),  and  the  Nuclear  Planning  System 
(NPS).92 

This  chapter  begins  by  reviewing  the  structure  of  the  TSGCE  and  the  work  of  TSGCE 
SGI  1  and  SG12  (Section  18.1).  It  further  examines  the  standards  specified  by  near-term  NATO 
and  multilateral  interoperability  demonstration  and  development  efforts  in  addition  to  ATCCIS, 
namely  the  ACE  ACCIS  (Section  18.2),  ACCS  (Section  18.3),  BICES  (Section  18.4),  NMOS 
(Section  18.S),  the  Quadrilateral  Interoperability  Programme  (Section  18.6),  and  STAMINA 
(Section  18.7).93  Military  features  required  by  NATO  are  addressed.  In  addition,  this  chapter 
addresses  some  of  the  issues  associated  with  evolving  from  near-tom  systems  to  ATCCIS  through 
the  use  of  standards.  Profiles  of  standards  that  are  to  be  used  in  transition  implementations  for 
several  NATO  projects  are  also  presented.94 

The  objective  of  this  review  is  to  ensure  that  the  methodology  used  for  the  ATCCIS  effort 
is  comprehensive  and  that  no  classes  of  relevant  standards  have  been  overlooked.  Some  national 
initiatives  to  adopt  and  extend  OSI  standards  for  tactical  employment  are  reviewed  in  Appendix  C. 


i  Quick  Reference  j 

Topic 

ACEACCtS 

306 

ACCS 

300 

AHWGon  ATCCtS 

306 

Architectural  issues 

420 

BICES 

404 

C3  Restructuring 

386 

CNSI 

414 

ISON  Issues 

428 

NATO  OSE  Ref.  Model 

418 

NATO  Software  Stds 

431 

NOTS 

414 

NMOS 

406 

OSI  Issues 

425 

PG6-Tee  Comma  2000* 

386 

Quadriiat  Interop  Prog 

406 

STAMINA 

410 

TCP/IP-OSI  Coex/Conv 

410 

TSGCE  SG11 

387 

TSGCE  SG12 

393 

WG2  on  Data  Proc/Mgt 

304 

92  ACCS,  Aims,  BICES,  JRMS.  NMOS.  NPS.  and  SCARS  Hare  the  seven  ACE  CCIS-reiated  projects 
identified  in  the  ACE  Inventory  of  Key  Tasks  [Ref.  ACE  1988]. 

93  The  information  provided  in  Section  18.2  through  18.7  was  reviewed  and  updated  by  SHAPE  staff  in 
January  1992  and  is  to  be  updated  again  through  further  discussions  hi  January  rod  February  1994. 

94  Profiles  differ  from  stacks  in  that  a  profile  usually  consists  of  several  stacks  of  standards  and  further  that 
profiles  are  usually  recommended  for  a  certain  transition  strategy  or  a  specific  implementation.  In  some  cases, 
profiles  specify  options  to  be  used. 

Chapter  18 


385 

UNCLASSIFIED 


NATO  Initiatives 


UNCLASSIFIED 


18.1  Standardisation  work  in  the  TSGCE 

18.1.1  Impact  of  NATO  C3  Restructuring  on  TSGCE 

C3  Restructuring.  In  January  1994  the  TSGCE  plenary  and  an  informal  meeting  of  the 
NACISC  addressed  proposals  for  restructuring  the  organization  and  responsibilities  of  the  TSGCE 
and  the  NACISC  and  supporting  elements.  Three  proposals  were  considered — noire  were  adopted 
but  none  were  found  unacceptable.  These  proposals,  derived  from  the  Anderson  Report  of 
December  1993,  were  the  following  [Ref.  Rannestad  1994]: 

•  Combine  TSGCE  and  NACISC  and  constitute  a  C3  Management  Board  to  oversee  die 
work 

•  Combine  STC  and  ADSIA  and  constitute  an  integration  center 

•  Combine  the  International  Military  Staff  (IMS),  comprising  about  83  people,  and  die 
International  Staff  (IS),  comprising  about  1 1  people,93  into  a  C3  Directorate/Defence 
Board. 

impact  on  TSGCE.  Reorganization  of  the  TSGCE  is  being  considered  whether  or  not 
TSGCE  and  die  NACISC  are  merged.  The  number  of  groups  within  the  TSGCE  has  already  been 
reduced  from  60  to  35;  reorganization  would  further  reduce  the  number  of  groups  to  12*16.  The 
proposal  from  the  TSGCE  Chairman  (also  the  UK  position)  January  1994  [Ref.  Goldon  1994] 
suggested  the  following  16  groups  for  TSGCE:96 

•  Communications  Standing  Group  derived  from  SG4,  to  address  communications 
systems  cooperation 

-  WG  on  tactical  (mobile)  communications,  derived  from  PG6 

WG  on  strategic  (fixed)  communications,  derived  from  SG9’s  AHWG  on  ISDN 
WG  on  satellite  communications,  derived  from  SGll’s  WG8 
PG  on  tactical  spectrum  management  system,  derived  from  PG8 
Steering  committee  on  Communications  System/Network  Interoperability, 
derived  from  SC  on  CSNI 

•  Information  Systems  Standing  Group  derived  from  SG4,  to  address  information 
systems  cooperation 

WG  on  electronic  mail  and  messaging  systems,  derived  from  SG9’s  AHWG  cm 
MMHS 

WG  on  data  links,  derived  from  SG9’s  WG4 

WG  on  information  systems  security,  derived  from  SG9’s  AHWG  on  Security 
WG  on  data  processing  and  management,  derived  from  SG12 
WG  on  data  fusion,  derived  from  SGI 2 

WG  on  software  engineering,  derived  from  SG12  and  acting  as  a  shared  group 
with  the  NACISC 

Steering  committee  for  BICES  Project  Management  Group,  derived  from  SC  on 
BICES 

•  Navigation  Systems  Standing  Group,  derived  from  SG4,  to  address  navigation 
systems  cooperation 

•  Identification  Systems  Standing  Group,  derived  from  SGS,  to  address  identification 
systems  cooperation 


93  Several  key  people  from  (be  IS  have  left  or  will  be  leaving  in  tfae  first  pvt  of  1994:  Seifert  (already  departed), 

A.  Ramestad,  ml  L.  Klein.  Not  ill  will  be  replaced 

96  The  United  States  has  recommended  that  SG12  be  disbanded  sad  its  work  be  accomplished  in  the  NACISC, 
not  tfae  TSGCE  At  present,  SG12  is  dormant  and  its  WG2  met  only  once  in  1993  (February). 
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18.1.2  Work  of  TSGCE  SG11  on  Communications 

TSGCE  SG11  on  Communications  (1)  promotes  collaboration  amongst  the  nations  on 
projects  to  develop  and  produce  common  equipment  and  systems  in  the  area  of  communications 
and  (2)  prepares  required  technical  STANAGs  for  communications  systems  and  equipment  The 
goal  is  to  promote  and  achieve  interoperability  between  national  and  NATO-funded  systems,  both 
tactical  and  strategic.97 

18.1.2.1  Organization  of  SG11 

At  the  November  1991  plenary  of  SG11,  SG11  reviewed  and  approved  the  terms  of 
reference  and  special  tasking  instructions  for  its  subgroups  and  subordinate  bodies.  The 
organization  of  SGI  1  is  as  follows  [Ref.  Pilla  1991]: 

•  WG1  on  Tactical  Area  Communications,  which  identifies  interface  requirements  and 
prepares  draft  new  or  modified  tactical  area  communications  STANAGs  in  die  areas  of 
terminal,  multiplexing,  switching,  and  multi-channel  radio  equipment  as  well  as 
interface  gateways  and  devices  among  tactical  systems,  strategic  systems,  and 
commercial  systems. 

•  WG2  on  Narrow-Band  Speech,  which  investigates  possible  speech  techniques  in 
order  to  achieve  high  quality  (under  adverse  acoustical  conditions)  of  reproduced  voice 
in  as  narrow  a  frequency  band  as  possible. 

•  WG3  on  Tactical  Communications  Equipment  for  Use  in  the  Maritime.  Fjvimnmmt 
which  identifies  interface  requirements  and  prepares  draft  new  or  modified  STANAGs 
for  secure  submarine,  air,  and  surface  communications  capabilities. 

•  WG5  mi  Single  Channel  Radio  Systems,  which  identifies  interface  requirements  and 
prepares  draft  new  or  modified  STANAGs  in  the  areas  of  single  channel  and  combat 
net  radios. 

•  WG8  on  Satellite  Communications  Systems,  which  identifies  interface  requirements 
and  prepares  draft  new  or  modified  STANAGs  in  the  areas  of  satellite 
communications. 

•  PG6  on  Tactical  Communications  Systems  for  the  Land  Combat  Zone— Post  2000. 
which  is  developing  technology  assessments,  an  agreed  tactical  communications 
architecture,  a  transition  strategy,  and  standards. 

•  PG8  on  Tactical  Spectrum  Management  System,  which  is  defining  a  NATO  tactical 
spectrum  management  architecture  and  identifies  opportunities  to  harmonize  current 
systems. 

18.1.2.2  Activities  of  the  Working  Groups 

SG11/WG2  is  planning  tests  for  low-rate  speed  coders  and  will  report  results  in  1992. 
Planning  for  testing  other  voice  coders  and  error  correction  devices  will  be  conducted  in  1992. 

SG11/WG5  is  developing  a  STAN  AG  for  High  Frequency  (HF)/Electronic  Counter- 
Counter  Measures  (ECCM);  the  initial  draft  for  circulation  to  the  nations  is  planned  March  1992. 
Work  has  begun  on  VHF  ECCM;  a  draft  STANAG  is  being  considered  for  VHF  interim 
interoperability  using  gateways  for  analog  voice.  Other  areas  of  interest  to  WGS  are  HAVE 
QUICK  II  radios  and  SATURN  radios  (STANAG  4372)  and  the  requirements  for  NATO 


97  The  informatioa  presented  an  the  wort  of  SG11  U  very  general.  This  is  more  deoiled  information, 
including  the  special  tasking  instructions,  reports  of  meetings,  and  most  of  the  formal  correspondence 
regarding  SGU  is  being  classified  as  NATO  RESTRICTED  by  the  NATO  Secretariat  Only  material 
available  at  the  unrtassifted  level  and  appropriate  for  wide  disseminsrion  has  been  used  herein. 
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Improved  Link  Eleven  (NILE).  WG5  reviewed  STAN  AGs  4203, 4204,  and  4205  in  1991  and 
will  review  STANAG  4202  in  1992. 

Canada,  France,  Germany,  the  United  Kingdom,  and  the  United  States  have  signed  an 
MOU  for  work  in  SG11/PG8  on  the  Tactical  Spectrum  Management  Program.  Spain  is  also 
considering  joining  this  program.  [Ref.  Howe  1991] 

18.1.2.3  Work  of  PG6  on  Poet-2000  Tactical  Communications** 

The  objective  of  the  work  of  SG11/PG6  is  to  seek,  through  a  coordinated  program,  tactical 
communications  systems  designed  to  common  standards,  to  include  collaborative  work  on 
subsystems  and  standards  development,  where  appropriate.  The  result  of  the  common  standards 
and  collaborative  work  on  subsystems  is  expected  to  be  the  achievement  of  progressively  enhanced 
interoperability. 

PG6  has  been  working  in  seven  areas:  architecture,  switching,  communications  media, 
mobile  systems,  terminals,  system  management,  and  security.  This  work  was  divided  into  three 
phases — planning,  study,  and  integration — and  has  resulted  in  a  description  of  the  recommended 
post-2000  architecture,  supported  and  justified  by  a  number  of  detailed  technology  studies.  Areas 
for  standardization  have  been  identified.  The  final  product  is  the  Phase  /  Final  Report  [Ref. 
TSGCE  1991j],  which  includes: 

•  An  operational  and  architectural  framework  for  tactical  communications  systems  for 
the  land  combat  zone  in  the  post-2000  time  frame 

•  A  list  of  standards  and  areas  for  standardization  work  within  this  framework 

•  Proposals  for  the  next  stage  of  work. 

The  framework  takes  into  account  national  ami  NATO  military  operational  requirements 
and  die  SHAPE  concept*9  for  tactical  communications  in  support  of  land  operations.  It  is  based  on 
several  pre-feasibility  studies  done  by  the  NIAG  (completed  in  1990)  and  under  a  multinational 
MOU.100  It  describes  the  preferred  architecture  and  identifies  essential  system  (interoperability) 
parameters. 

The  report  identifies  standards  and  areas  for  standardization  required  for  equipment 
development  according  to  the  preferred  architecture.  PG6  identifies  the  existing  STANAGs  that  fit 
the  architecture,  the  existing  STANAGs  that  may  need  modification,  and  areas  for  standardization 
in  which  new  STANAGs  or  other  standards  will  need  to  be  written. 

The  next  phase  of  work  encompasses  defining  the  architecture  in  greater  detail,  to  include 
the  functional  and  performance  aspects,  in  order  to  reach  the  level  of  detail  needed  to  prepare  the 
STANAGs,  as  well  as  the  system-  and  subsystem-level  specifications.  In  addition,  PG6  is 
planning  on  a  limited  number  of  studies  to  enhance  die  base  knowledge  in  rapidly  changing  or  new 
technologies  applicable  to  communications.  The  products  for  1992-93  are  expected  to  include  (1) 
elaboration  of  the  agreed  architecture  in  more  detail  and  (2)  confirmation  of  the  transition  strategy. 


**  Material  hi  this  section  is  based  on  a  private  communication  with  Sal  Manno  (US  Representative  to  PG6), 
JTC3A,  9  December  1991. 

99  Only  drafts  of  the  concept  were  completed  during  the  first  phase  of  the  PG6  architectural  work.  These  drafts 
have  now  been  withdrawn  and  a  new  tactical  communications  coocept  is  in  preparation.  When  completed. 
ATCA  intends  to  work  on  a  military  operational  requirement  based  on  the  tactical  communications  concept 

100  The  1991  partidpanu  hi  the  MOU  were  Canada,  France,  Germany,  Italy,  the  Netherlands,  Norway,  Spain,  the 
United  Kingdom,  and  the  United  States.  The  MOU  covers  a  number  of  pre-feasMlity  studies  that  extend  the 
work  completed  by  the  NIAG.  Portugal  as  indicated  interest  in  joining  the  MOU  for  work  in  1992. 
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For  die  period  1994-1997,  the  emphasis  in  FG6  will  be  on  the  development  of  standards  for  the 
post-2000  era. 

SG11  has  agreed  that  PG6  be  given  the  systems  engineering  responsibility  for  all  SG11 
work  related  to  the  PG6  tactical  communications  system  architecture  and  that  SG11  manage  all  die 
SGI  1  work  and  schedules  within  the  framework  of  that  architecture.  The  overall  concept  was 
endorsed  by  SG11  in  November  1991,  and  PG6  was  requested  to  provide  a  comprehensive  work 
plan  for  submission  to  SGI  1.  [Ref.  Manno  1991a] 

SGI  1  has  been  asked  by  the  TSGCE  to  provide  a  schedule  at  the  January  1992  TSGCE 
plenary  for  the  completion  of  two  CNAD  tasks:  (1)  interoperable  communication  links  for  tactical 
headquarters  and  (2)  interconnection  of  tactical  and  strategic  communications  systems.  SGI  1  has 
also  been  asked  by  the  TSGCE  to  assist  in  expediting  agreements  necessary  to  make  HAVE 
QUICK  HA  algorithms  available  to  SATURN  radios  and  to  respond  to  a  Conventional  Armaments 
Plan  tasking  for  a  second  generation  ECCM  UHF  program  (and  report  to  the  TSGCE  in 
June  1992).  [Ref.  Howe  1991] 

18.1.3  Communications  Architecture  Post-2000 

PG6  was  initiated  in  1989  under  a  memorandum  of  understanding  entitled,  “Cooperative 
Pre-feasibility  Studies  for  Tactical  Communications  Systems  for  the  Land  Combat  Zone — Post 
2000.”  The  aim  of  PG6  is  the  development  of  standards  recommendations — based  on  current  and 
future  civil  standards — for  a  land-based,  interoperable  tactical  communications  system  for  the  post- 
2000  era.  The  first  phase  of  PG6  was  completed  at  the  end  of  1991  with  the  recommendation  of 
an  architecture,  designed  to  be  extremely  flexible  and  making  use  of  advanced  telecommunication 
developments  in  the  military  as  well  as  civilian  environments.  The  second  phase,  now  underway, 
is  focused  on  refining  the  architecture  and  adding  standardization  areas;  it  is  expected  to  be 
completed  in  the  first  half  of  1994.  [Ref.  Thieme  1993] 

The  architecture  addresses  such  requirements  as  [Ref.  Valuer  1993]: 

•  Increased  mobility  of  military  forces,  requiring  a  communication  system  with  an 
extremely  high  degree  of  mobility  and  economy 

•  Higher  degree  of  assured  availability  and  security  for  mobile  users 

•  Introduction  of  advanced  C3I,  requiring  high  bit-rate  systems,  at  least  within 
headquarters,  and  hence  more  flexible  use  of  the  available  bandwidth,  to  include  both 
high-speed  data  and  video  communications 

•  More  extensive  use  of  computer  systems  and  data,  requiring  interfaces  to  mobile  users 
(e.g.,  via  packet  radio) 

•  Automated  message  handling  system  with  connections  to  the  public  X.400  service 

•  Radio  relays  with  higher  bandwidth  and  lower  probability  of  enemy  detection, 
obtained  from  use  of  higher  frequency  (e.g.,  60  GHz)  transmissions 

•  Operability  between  military  units  from  different  nations,  requiring  fully  interoperable 
communications  systems  with  attendant  network  management  services. 

The  architecture  includes  a  multi-role  radio  that  can  be  used  for  single-channel  radio  access 
(SCRA),  combat  net  radio,  and  packet  radio  applications,  in  both  voice  and  data  transmission 
modes.  The  architecture  recommends  the  asynchronous  transfer  mode  (ATM)  for  basic  switching 
and  transmission,  enabling  efficient  and  dynamically  responsive  use  of  available  bandwidth. 
Telecommunications  management  network  (TMN,  CCITT  M.30),  based  on  an  object-oriented 
approach,  and  CMIS/CMIP  are  recommended  for  network  management  services.  The  Local  Area 
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System  (LAS)  component  of  the  architecture  covers  communication  needs  of  a  tactical  (corps, 
division,  and  brigade)  headquarters,  for  which  staffs  are  expected  to  be  distributed  (e.g.,  over  an 
area  of  one  square  kilometer).  Staff  sections  would  be  equipped  with  a  small  ATM  node  with 
broadband  interconnections  over  fiber  optic  cables  or  60-GHz  radio  relays,  giving  trunk  capacities 
in  die  order  of  100  Mbps.  LAS  subscriber  connections  would  use  either  the  EUROCOM  “K” 
interface,  ISDN  basic  access,  or  broadband  ATM  interface  at  about  20  Mbps.  The  need  for 
TCP/EP  stacks  as  well  as  OSI  stacks  is  recognized  as  part  of  the  transition  strategy.  The  Wide  Area 
Subsystem  (WAS)  is  designed  to  cover  an  entire  theater  of  operations  with  a  truck  network,  using 
such  technologies  as  variable-bit-rate  transmission,  dynamic  anti-jamming,  and  other  electronic 
counter-countermeasures.  Long-distance,  line-of-sight  radio  relays  in  the  UHF  to  SHF  bands  will 
be  capable  of  bit  rates  of  2-10  Mbps.  Troposcatter  and  satellite  communications  may  also  be  used 
as  a  supplementary  overlay  for  direct  interconnection  of  nodes  extremely  far  apart  WAS  will  not 
offer  broadband  ATM;  hence,  data  and  video  communications  will  be  limited  to  about  64  kbps, 
which  can  be  handled  by  ISDN.  Mobile  User  Subsystem  (MUS)  subscribers  will  use  a  Multi-Role 
Radio  (MRR)  and  interconnect  with  the  WAS  using  radio  access  points  (RAPs)  connected  directly 
to  a  switch  port  in  a  LAS  or  WAS. 

PG6  has  conducted  analyses,  modelling,  and  simulation  to  explore  the  feasibility  of  the 
standards  recommended  in  the  architecture.  One  of  these  (conducted  by  TNO  [Ref.  Thierae  1993]) 
explored  the  use  of  DIS  8802-6  (IEEE  802.6) — a  MAN  standard  also  known  as  distributed  queue 
dual  bus  (DQDB) — for  the  LAS  command  post  network.  Requirements  for  the  LAS  include: 

•  Survivability  that  guarantees  operation  of  the  LAS  by  minimizing  effects  of  faults  be 
means  of: 

Automatic  by-passing  or  isolation  of  faulty  stations 
Built-in  redundancy  and  alternative  paths  (back-up  links) 

Automatic  reconfiguration  and  rerouting 

Stand-alone  operation  of  any  non-damaged  part  of  the  network 

Low  probability  of  intercept  (LPI)  and  detection 

•  High  mobility  so  as  not  to  restrict  tactical  operations 

Automatic  by-passing  or  isolation  of  faulty  stations 

•  Levels  of  precedence  to  allow  timely  information  exchange  under  all  combat 
conditions,  including  seizure  (preemption)  of  transmission  service,  assets,  and 
terminals  used  to  serve  lower-precedence  levels 

•  Multimedia  transmission  support,  including  speech,  data  communications  (text, 
graphics,  speech,  high-definition  pictures,  and  video),  and  video  communications 
(video  telephony  and  video  conference). 

The  TNO  study,  modelling,  and  simulation  had  positive  conclusions  on  the  use  of  the 
DQDB  MAN  standard.  DQDB  based  on  fiber  optic  transmission  systems  can  be  a  good  basis  for 
LANs  in  the  LAS.  Within  a  DQDB  bus,  millimeter-wave  transmission  systems  can  also  be  used, 
but  it  is  not  very  effective  to  use  more  than  a  few  radio  links  on  a  bus  that  used  the  DQDB 
protocol.  When  building  a  more  complex  network  to  support  dispersed  command  posts,  several 
DQDB  subnetworks  should  be  used  that  can  be  coupled  using  millimeter-wave  radio  transmission 
means.  The  available  speeds  of  DQDB  (133  Mbps)  are  sufficient  to  achieve  the  desired  quality  of 
service.  Finally,  additional  research  is  needed  to  enhance  the  standard  so  that  it  will  be  able  to 
(1)  keep  isochronous  connections  during  reconfiguration  of  the  bus  and  (2)  use  a  common  priority 
mechanism  for  connectionless  ami  isochronous  service. 
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18.1.3.1  NATO  Tactical  Communication*  Architecture  Post-2000 

The  major  components  of  the  NATO  Tactical  Communications  Architecture  Poet-2000 
being  developed  by  PG6  are  a  Local  Access  Subsystem  (LAS),  a  Wide  Area  Subsystem  (WAS), 
and  a  Mobile  Subsystem  (MS).  Figure  22  depicts  an  extended  LAS  component  with  three 
interconnected  LASs. 


Figure  22.  Post-2000  Tactical  Communications  ArchRocturs-Extsndsd  LAS 

The  LAS  provides  the  means  for  user  access  to  die  WAS  and  for  local  communications 
services  in  die  local  area.  Additionally,  it  provides  interfaces  to  the  civilian  commercial  network. 
The  LAS  is  composed  of  distributed  access  LANs  and  centralized  access  PABXs  connected  by 
dual  fiber  optic  rings  (see  Figure  22).  The  access  LANs  provide  service  access  for  a  distributed 
community  of  interest  to  the  dual  ring  LAN,  while  the  PABXs  represent  die  interconnection  of 
existing  switching  equipment  to  the  new  network.  The  PABX  will  be  phased  out  and  replaced  by 
LAN  technology  as  the  architecture  evolves  into  the  future.  The  dual  ring  LAN  has  a  wide- band 
Asynchronous  Transfer  Mode  (ATM)  switch  that  provides  access  to  other  LAS  rings  via  a  LAS 
radio  or  to  the  WAS  nodes  via  WAS  radio  links.  The  LAS  radio  is  also  used,  as  well  as  fiber  optic 
cable,  to  extend  the  dual  ring  in  the  event  of  a  geographical  obstacle.  User  access  to  the  LAS  is  via 
a  single  channel  providing  integrated  (voice,  data,  and  video)  services  either  separately  or 
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simultaneously.  User  terminals  are  envisioned  to  function  similarly  to  commercial  ISDN 
terminals,  using  ISDN-type  signalling  and  message  sets  modified  for  tactical  use  to  control  and 
request  access  to  integrated  user  services. 

The  WAS  provides  long-haul  transport  and  switching  of  user  services  through  die  tactical 
network  as  well  as  local  access  to  users  in  the  vicinity  of  a  WAS  node.  WAS  nodes  are  really 
extensions  (explosions)  of  the  LAS  architecture  with  longer-range  transmission  and  greater  variety 
and  number  of  transmission  resources.  ATM  technology  is  used  to  replace  fixed-bit-rate  circuits 
with  flexible  virtual  circuits  in  which  capacity  is  negotiated  on  an  as-needed  basis.  The  ATM 
capability  of  the  WAS  architecture  will  replace  current-generation  circuit,  packet,  and  message 
switches  with  fast  "asynchronous"  packet  switches.  These  switches  will  be  linked  by  wideband 
trunks  in  which  the  full  capacity  of  the  radio  link  will  be  available  to  the  switch  as  a  single 
wideband  circuit  rather  than  multiplexed  narrow-band  timc-di vision-multiplexed  circuits.  The 
ATM  switch  will  statistically  multiplex  the  instantaneous  demand  for  virtual  circuit  service  from 
diverse  end  users  on  this  single  wideband  channel. 

18.1.3.2  Post-2000  NATO  Reference  Model 

PG6  has  also  developed  a  conceptual  Post-2000  NATO  Reference  Model  for  use  with  the 
future  tactical  communications  architecture  with  seven  layers  (not  identical  with  die  OSI  and  current 
NATO  Reference  Model):  Media  Layer  1,  Access  Layer  2,  Routing  Layer  3,  End-to-End  Layer  4, 
Session  Layer  5,  Presentation  Layer  6,  and  Application  Layer  7.  The  upper  layers  and  the  protocol 
stacks  envisioned  for  network  management  protocols  for  the  Post-2000  Tactical  Communications 
Architecture  are  shown  in  Table  39. 

18.1.3.3  NATO  C3  Physical  Communications  Architecture 

In  May  1992,  NAOSA  published  the  NATO  C3  Physical  Communications  Architecture- 
Recommended  Topology  [Ref.  NACISA  1992],  which  established  a  generic  switched  network 
architecture  for  the  1990s.  For  NATO’s  circuit-switched  needs,  the  study  recommended  that 
NATO  should  field  a  hybrid  network  consisting  of  three  components:  (1)  a  NATO  Core  Network 
(NCN)  consisting  of  integrated  services  PABXs  (ISPABXs),  (2)  services  provided  by  national 
defense  networks,  and  (3)  public  switched  telephone  network  (PSTN)  services.  The  primary 
purpose  of  the  latter  two  components  was  to  provide  cost-effective  service  for  remote  NATO 
subscribers,  alternate  routing,  overflow  capacity,  and  increased  survivability.  The  size  of  the 
NCN  and  the  degree  of  services  sought  from  the  national  defense  and  PTT  networks  was  to  be 
based  on  the  most  cost-effective  solution.  [Nevergold  1993] 

A  number  of  conclusions  can  be  drawn  from  the  studies  and  analyses  of  [Nevergold  1993]. 
Given  the  technology  existing  today,  NATO’s  circuit-switched  communications  needs  are  best 
served  by  a  hybrid  network  consisting  of  a  NATO  Core  Network  that 
(1)  provides  switched  services  to  users  located  at  major  NATO  headquarters,  (2)  interconnects 
national  defense  networks,  and  (3)  uses  national  PTT  networks  to  increase  survivability  and 
accessibility  to  remote  users  in  a  cost-effective  combination.  The  cost  of  the  NATO  Core  Network 
is  driven  by  transmission  costs.  Total  network  cost  is  largely  independent  of  the  number  of  core 
switches  in  the  range  of  interest;  therefore,  other  considerations  such  as  survivability,  availability 
and  subscriber  access,  which  can  vary  with  the  number  of  switches,  can  be  improved  without 
adversely  affecting  cost 
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Table  M.  Propone d  NATO  Poat-2000  Network  Management  Protocol* 


MANAGEMENT  APPLICATION  PROCESS 


OS  SESSION  LAYER 
oerrr  X2is.  x^26:  bo  naa.  aaz7 


OSI  TRANSPORT  LAYS) 
OCfTT  )C214.  X224;  BO  *072.  M73 


LOCAL  AREA 
SUBSYSTEM 


WOE  AREA 
SUBSYSTEM 


LAYER 

7 


LAYER 

« 


LAYER 

S 


LAYER 

4 


Souks:  Sutyoctfr*  Evaluation  of  Candkfa*  Archhecturaa  tor  tha  Tactical  Communication*  Syutarm 
Land  Combat  Zona  Poat  200.  Draft,  Prapanad  by  tha  Unilad  Suras  for  TSGCE  PQe.  10  May  1M1, 
NATO  UNCLASSIFIED. 


18.1.4  Work  of  TSGCE  SG12  on  Information  Systems1*1 

TSGCE  SG12  mi  Information  Systems  was  established102  by  the  TSGCE  to  (1)  promote 
and  enable  collaboration  among  the  nations  of  the  Alliance  on  projects  to  develop  and  produce 
common  equipment  and  systems  in  die  area  of  information  systems  and  (2)  provide  technical 
standards  in  die  area  of  information  systems.  The  goal  was  to  promote  and  enable  the  achievement 
of  interoperability  between  and  among  national  and  NATO-funded  CCISs,  both  tactical  and 
strategic.  SG12  has  two  subordinate  bodies,  which  will  establish  a  close  working  relationship 
with  each  other. 

•  WG2  on  Data  Pmcessiny  and  Management  which  will  recommend  standards  on  data 

processing  and  security  with  ADP  systems. 

•  AHWG  on  an  Army  Tactical  Command  and  Control  Information  System  ( ATCCIS). 
which  is  emphasizing  data  management  and  exploiting  the  Phase  I  and  Phase  II 
technical  work  on  a  standards- based  architecture  during  1984-91  by  France,  Germany, 
the  United  Kingdom,  and  die  United  States. 


101  Thti  section  is  based  on  the  Report  to  the  Tri-Service  Group  by  the  Chairman  of  the  Subgroup  on 
Information  Systems,  AC/302<SGfl2)Df7, 21  November  1991,  NATO  UNCLASSIFIED. 

102  Neither  SG12  nor  in  only  working  group  (WG2)  met  in  1993  due,  in  part,  to  concern  by  some  nations 
(notably  the  United  States)  that  work  of  SG12  overlaps  the  responsibilities  of  the  Information  System 
Working  Group  of  the  NACISC.  This  overlap  is  the  subject  of  farther  discussions  for  restructuring  NATO 
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Two  other  TSGCE  groups,  originally  assigned  to  SG12  during  the  initial  work  on  TSGCE 
restructuring,  have  now  been  directed  by  the  TSGCE  to  continue  reporting  directly  to  the  TSGCE. 
They  are  the  Project  Group  (PG7)  on  BICES  and  the  Special  Working  Group  on  Ada 
Programming  Support  Environment  (APSE)  (this  group  had  been  renamed  Working  Group  on 
Software  Engineering  when  it  was  considered  part  of  SG12).  Eleven  nations  have  been 
participating  in  die  MOU  on  BICES  and  two  others  are  expected  to  join.  The  Working  Group  on 
Geographic  Information  Systems,  initially  assigned  to  SG12,  has  been  transferred  to  the  Military 
Agency  for  Standardization  (MAS). 

18.1.4.1  WG2  on  Data  Processing  and  Management 

Table  60  shows  the  special  tasking  instructions  for  WG2  that  govern  its  work.  The  initial 
program  of  work  for  SG12/WG2  is  as  follows  [Ref.  TSGCE  1991m]: 

•  Data  Management  Reference  Model  (DMRM)  and  Architecture 

Monitor  the  status  of  work  in  ISO  and  other  relevant  international  standardization 
groups 

Review  the  products  of  other  relevant  study  groups,  with  particular  reference  to 
the  A70CIS  study  and  the  emerging  NATO  Data  Management  Policy. 

Determine,  by  reference  to  recognized  user  representatives  at  the  strategic  and 
tactical  levels,  thr  requirements  for  the  NATO  DMRM  and  architecture. 

Identify  t!  'ossibte  options  for  die  selection  of  a  NATO  DMRM  and  architecture 

and  make  ,  ropriate  recommendations. 

lime  scale  and  milestones  are  to  be  determined;  lead  nation  is  France. 

•  Data  Models 

Monitor  the  status  of  work  in  OSI  and  other  relevant  international  standardization 
groups. 

•  Review  the  products  of  other  relevant  study  groups,  with  particular  reference  to 
the  ATCC2S  study  and  the  emerging  NATO  Dota  Management  policy. 

•  Determine,  by  reference  to  recognized  user  representatives  at  die  strategic  and 
tactical  levels,  the  requirements  for  data  models  and  in  particular  make 
recommendations  as  to  the  number  and  type  of  distinct  models  required. 
Determine  the  requirements  for  the  production  (by  others)  of  an  initial  data 
model(s)  and  for  subsequent  maintenance  of  that  model(s). 

Identify  a  suitable  set  of  software  tools  and  aid  packages  to  assist  in  the  creation 
and  maintenance  of  such  models,  and  make  appropriate  recommendations. 

Time  scale  and  milestones  are  to  be  determined;  lead  nation  is  the  United 
Kingdom. 

•  Data  Dictionaries 

Monitor  the  status  of  work  in  ISO  and  other  relevant  international  standardization 
groups. 

Determine,  by  reference  to  recognized  user  representatives  at  the  strategic  and 
tactical  levels,  the  requirements  for  data  dictionaries. 

Determine  the  requirements  for  the  reproduction  (by  others)  of  an  initial  data 
dictionary  from  the  NATO  Data  Model(s)  and  for  subsequent  maintenance  of  that 
dictionary. 

Identify  the  possible  options  for  the  selection  of  a  NATO  standard  for  data 
dictionary  definition,  and  make  appropriate  recommendations. 

Define  the  structure  of  a  NATO  data  dictionary  using  an  appropriate  meta¬ 
language. 
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Identify  a  suitable  set  of  software  tools  and  aid  packages  to  assist  in,  or  to 
automate,  the  process  of  converting  a  data  model  into  a  set  of  data  definitions  for 
incorporation  into  a  NATO  data  dictionary. 

Be  prepared  to  respond  to  specific  queries  by  the  provision  of  technical  advice  to 
staff  responsible  for  the  management  of  the  NATO  data  dictionary. 

Time  scale  and  milestones  are  to  be  determined;  lead  nation  is  the  United 
Kingdom. 

•  Data  Definition  and  Data  Schemata 

Monitor  the  status  of  work  in  ISO  and  other  relevant  international  standardization 
groups. 

Review  the  products  of  other  relevant  study  groups,  with  particular  reference  to 
the  ATCCIS  study  and  the  emerging  Data  Management  Policy. 

Determine  by  reference  to  recognized  user  representatives  at  the  strategic  and 
tactical  levels,  the  requirements  for  data  schemata. 

In  consultation  with  appropriate  NATO  and  National  Staff,  determine  the 
requirements  for  the  production  and  subsequent  maintenance  of  data  schemata. 
Identify  a  suitable  set  of  software  tools  and  aid  packages  to  assist  in,  or  to 
automate,  the  process  of  generating  data  schemata  from  a  NATO  data  dictionary, 
and  make  appropriate  recommendations. 

Be  prepared  to  respond  to  specific  queries  by  the  provision  of  technical  advice  to 
stan  responsible  for  NATO  projects. 

Time  scale,  milestones,  and  lead  nation  are  to  be  determined. 

•  Data  Access  and  Manipulation  Standards 

Monitor  the  status  of  work  in  ISO  and  other  relevant  international  standardization 
groups. 

Review  the  products  of  other  relevant  study  groups,  with  particular  reference  to 
the  ATCCIS  study  and  the  emerging  NATO  Data  Management  Policy. 

Identify  the  possible  options  for  the  selection  of  NATO  standard  access  and 
manipulation  languages,  and  make  appropriate  recommendations. 

Identify  software  tools  and  aid  packages  appropriate  to  assist,  or  to  automate,  the 
generation  of  applications  from  initial  analysis  and  outline  definition  of  functional 
requirements  (CASE  tools),  in  conformity  with  the  standards  recommended. 
(This  activity  is  seen  as  providing  guidance  and  is  not  to  be  taken  to  imply  that  die 
Working  Group  will  endorse  any  particular  products  nor  undertake  any  form  of 
market  survey.) 

Time  scale,  milestones,  and  lead  nation  are  to  be  determined. 

18.1.4.2  AHWG  on  ATCCIS 

The  SG12  AHWG  on  ATCCIS  held  its  first  meeting  on  June  1991  (this  group  is  now 
inactive,  having  not  met  in  1992  or  1993).  The  meeting  was  organizational  and  focused  on  the 
relation  of  the  existing  ATCCIS  groups  (specifically  the  Permanent  Working  Group  and  its  two 
subordinate  groups,  the  Operational  Subgroup  and  the  Technical  Subgroup).  It  was  noted  that  die 
Operational  Subgroup  is  currently  meeting  (with  additional  national  participation  from  Canada  and 
the  Netherlands)  as  an  ad  hoc  working  group  under  the  Operational  Procedures  Working  Party  of 
the  MAS  Army  Board.  One  suggestion  was  that  the  AHWG  on  ATCCIS  similarly  meet  with  all 
interested  national  participation  simultaneously  with  the  existing  ATCCIS  Technical  Subgroup, 
which  would  avoid  creating  a  new  standards  body  and  resulting  overlapping  efforts.  In 
September  1991,  the  TSGCE  noted  a  recommendation  that  SHAPE  retain  operational  sponsorship 
of  ATCCIS,  that  die  existing  ATCCIS  groups  remain  in  effect,  and  that  a  relationship  between 
ATCCIS  and  the  TSGCE  be  established.  The  terms  of  reference  for  the  AHWG  on  ATCCIS,  as 
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well  as  the  terms  of  reference  for  SG9,  SGI  1,  SG12,  and  their  subordinate  bodies,  were  reviewed 
by  the  TSGCE  in  January  1992.  [Ref.  Howe  1991] 

Table  60.  Proposed  Tasking  instructions  for  SG12/WG2  on  Data  Processing  and 

Nanagsmant 


1.  Th«  working  group  «haii  adopt  tho  following  definition  of  Information  System  for  the  purpose  of  defining  the 
scope  of  its  actMties:  Data  processing  system  which  are  used  in  support  of  C3I  processes  within  NATO  and 
the  nations,  axdudng  embedded  system  within  sensor  system  and  weapons  platforms.  The  requirements  of 
development  system  (for  developing  hardware  and  software)  shal  be  excluded  from  the  scope  of  the  Working 
Group. 

2.  The  Working  Group  shall  work  in  close  association  and  harmonization  with  the  SG12  Working  Group  on 
Software  Engineering. 

3.  The  Working  Group  shall  ensure  that  al  ST  AN  AGs  developed  by  the  Group  are  based  to  the  greatest  extent 
possible  on  existing  or  emerging  civilian  standards. 

4.  The  Working  Group  is  required  to  undertake  the  following  tasks: 

a.  Maintain  a  corporate  up-to-date  knowledge  of  present  and  planned  NATO  and  national  data  processing  and 
management  system. 

b.  Identify,  review,  and  prioritize  the  requirement  for  standards  for  data  processing  and  management  systems. 

c.  Take  account  of  related  activities  in  NATO  and  in  particular  the  activities  of  TSGCE  SGB  and  its  subekSaty 
bodies;  AC/317,  including  ISWG,  ADSIA,  ACCSA,  and  NACISA;  AC/35;  STC;  DRG;  Inter-Service 
Geographic  Working  Group;  and  establish  effective  means  of  liaising  with  these  and  other  bodies,  both 
within  and  outside  NATO  (such  as  ISO),  so  as  to  astabHsh  prioritized  requirements  and  avoid  duplication  ol 
effort  and  activities. 

d.  Identify  and  review  existing  and  emerging  standards  for  data  processing  and  management  system  to 
enable  it  to  make  recommendations  for  the  adoption  or  enhancement  of  these  standards  for  cotaborative 
NATO  and  national  projects,  consistent  with  meeting  the  identified  minimum  military  requirement  and  in 
accordance  with  authoritative  advice  and  poSey  on  security  matters  from  AC/35  and  ACCSA. 

e.  Develop  STANAGs,  in  accordance  with  these  recommendations,  to  ensure  interoperability  of  NATO  and 
national  data  processing  and  management  systems. 

f.  PronKtenwasures  for  impro’ing  the  efficiency  of,  and  reducing  the  cost  of,  the  procurement,  operation,  and 
maintenance  of  NATO  a.  id  national  data  proceesing  and  management  systems  including,  where  appropriate, 
the  development  of  STANAGs. 

5.  The  Working  Group  sha,,  report  at  regular  Intervals  to  SG12  and  produce  a  forward  plan  of  work  for  agreement 
by  the  Subgroup.  This  work  plan  is  to  identify  both  the  areas  of  interest  of  the  Working  Group  and  the 
documents  which  will  be  produced  as  doBverabie  outputs  to  the  Subgroup. 

Source:  tasking  Instruction*  hr  tho  Working  Group  on  boto  Procoooing  ond  Manogomont,  Appendix  2  to  Annex  II 
to  AC/302-D/616,  Report  to  tho  Tri- Service  Group  by  tho  Cholrmon  of  Subgroup  on  Informotion  Syttomt, 
AC/302(SG/12)D7,  November  1391.  NATO  UNCLASSIRH). 

The  proposed  tasks  of  the  AHWG  on  ATCCIS  were  to  [Ref.  ATCCIS  1991]: 

•  Assist  the  TSGCE  in  identifying  standards  or  standards  parameters  required  for 

interoperability  of  tactical  land  force  ACCIS  identified  in  the  ATCCIS  effort 

•  Review  and  coordinate  ATCCIS  working  papers  for  TSGCE  acceptance  and 
promulgation. 

•  Document  and  address  key  technical  standards  issues  attendant  to  the  emergence  of 
ATCCIS  conformant  systems. 

18.2  ACE  ACCIS 

The  term  "Allied  Command  Europe — Automated  Command  and  Control  Information 
System"  (ACE  ACCIS)  reflects  the  intended  aim  of  a  common  ACCIS  architecture  to  be  applied  in 
a  uniform  way  across  ACE  (i.e.,  to  provide  automation  support  for  NATO  Headquarters  at 
echelons  above  corps). 

Current  ACE  ACCIS  Specifications.  The  following  are  the  key  documents  in 
defining  the  future  work  by  NATO  on  ACE  ACCS: 
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•  ACE  ACCIS  Implementation  Strategy  (AAIS),  NACISC,  June  1993  [Ref. 
ACEACCIS  1993a] 

•  ACE  ACCIS  Target  Architecture,  Director  General  NACISA,  September  1993, 
NACISC,  June  1993  [Ref.  ACE  ACCIS  1993b;  ACE  ACCIS  1993c] 

•  ACE  ACCIS  Core  Capability  and  Capability  Increments,  Draft  for  SHAPE 
Coordination,  NACISC,  January  1994  [Rdf.  ACE  ACCIS  1994a] 

•  NATO  Open  Systems  Environment  (OSE) — Baseline  Architectural  Principles  and 
Reference  Model,  NACISC/ISWG,  July  1993  [Ref.  NATO  OSE  1993] 

•  NATO  Data  Management  Policy,  AC/3 17-D/61 ,  NACISC,  June  1993,  [Ref.  NACISC 
1993a]  (approved  by  the  CSWG/ISWG  with  the  following  caveat:  that  the  formal 
attribution  of  the  specific  tasks  to  the  TSGCE,  within  the  policy  document,  is  not 
currently  agreed  and  that  the  formal  attribution  of  these  tasks  will  be  finalized  once  die 
wider  issue  is  resolved  as  a  result  of  the  accepted  outcome  of  the  C3  Restructuring 
Study). 

Architectural  Design  Study.  A  major  ACE  command  and  control  information  system 
study — the  ACE  Architectural  Design  Study  (ADS) — was  conducted  between  March  1980  and 
1982.  The  aims  of  the  ADS  were  to: 

•  Identify  those  command  and  control  related  activities  of  the  ACE  headquarters  that  lend 
themselves  to  ADP  support 

•  Consider  the  additional  requirements  of  interfaces  to  national  systems, 
communications,  and  resources 

•  Define  an  ADP  architecture  that  provided  the  required  support  to  command  and  control 
in  die  "most  operational  and  cost  effective  way" 

•  Define  an  implementation  strategy  to  provide  early  implementation  at  an  acceptable  cost 
and  effort 

System  Design  and  Integration  Contract.  The  system  definition  project  for  the 
ADS  was  known  as  the  System  Design  and  Integration  Contract  (SD&IC).  The  contract  was  let  to 
a  multi-national  consortium  and  was  originally  planned  to  cover  the  period  from  1989  throughlate 
1991.  Although  the  study  was  ACE-wide,  it  concentrated  on  SHAPE  and  the  Central  and 
Southern  Regions,  taking  account  of  the  need  for  interoperability,  economy,  and  manpower.  The 
SD&IC  attempted  to  develop,  as  far  as  possible,  a  common  system  design  for  ACE  ACCIS. 

The  SD&IC  had  two  major  objectives:  (1)  to  complete  the  system  architecture  for  ACE 
ACCIS  and  (2)  to  prepare  for  the  next  generation  of  ACE  ACCIS  nodes  in  SHAPE  and  the  Central 
and  Southern  Regions. 

Due  to  unforeseen  difficulties  the  SD&IC  fell  behind  in  time  scale  and  budget,  which  when 
combined  with  a  changing  political  and  military  situation,  resulted  in  some  of  the  products  no 
longer  meeting  the  "current"  situation. 

The  difficulties  experienced  in  concluding  the  SD&IC  resulted  in  the  contract  being 
terminated  before  completion  and  the  emphasis  being  placed  on  evolutionary  acquisition  of  ACE 
ACCIS  as  defined  in  the  AAIS,  which  defines  the  implementation  of  individual  ADP  systems 
building  toward  an  agreed  architecture. 
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STC  Testbed  Laboratory.  STC  has  developed  a  testbed  laboratory103  designed  to 
demonstrate  concepts  for  ACE  ACCIS  and  other  headquarters  information  systems  (HISs). 
Initially  the  testbed  provides  a  message  handling  network  interconnecting  headquarters  units  that 
have  very  different  message  and  decision  support  functionality.  Some  units  are  assumed  to  be 
limited  to  generation  and  display  of  message  text  formats,  while  others  are  capable  of  storing 
messages  in  command  databases  and  exchanging  decision  support  data  (such  as  graphics 
displays).  The  testbed  is  based  on  commercial  off-the-shelf  products  (e.g.,  SUN,  UNIX,  and 
X- Windows)  and  is  capable  of  [Ref.  STC  1991a]: 

•  Message  handling  over  NATO  TARE  and  OSI  networks 

•  Support  of  generic  user  functions  such  as  briefing  contributions  and  message 
processing 

•  Interoperability  with  other  CCISs,  including  transfer  of  decision  support  data. 

The  network  for  these  capabilities  is  the  NATO  TARE  wide  area  network  supported  by  a 
SHAPE  Information  Bow  (SHIF)  gateway  to  workstations,  personal  computers,  and  other 
command  and  control  systems  [e.g..  Limited  Operational  Capability — Europe  (LOCE)]. 

STC  is  using  for  its  laboratory  two  prototype  CCIS  configurations.  The  War  Headquarters 
Information  Dissemination  and  Display  System  (WHIDDS)  is  installed  in  the  SHAPE  bunker 
command  room  to  interconnect  the  staff  cells  with  a  central  Headquarters  database  (based  on  DEC- 
VMS,  DECNet,  and  FORTRAN  77).  Another  system,  LENA-2,  was  developed  at  STC  and  is 
being  maintained  by  SHAPE.  An  integrated  COS,  LENA-2  is  designed  to  support  the  Alternate 
War  Headquarters  (AWHQ)  or  other  HQ  COS  requirements.  LENA-2  is  based  on  SUN,  UNIX, 
and  X-Windows.  Interoperability  for  the  testbed  laboratory  is  via  X.400  and  ADatP-3  messages. 

ACE  ACCIS  Target  Architecture.  The  ACE  ACCIS  Target  Architecture  consists  of 
an  architecture  baseline,  ACE-level  architecture,  node-level  architecture,  security  architecture, 
discussion  of  system  management,  and  recommendations  on  implementation-related  standards. 
The  baseline  identifies  the  following  elements  and  supporting  mechanisms  as  essential: 

•  Interoperability  between  ACE  ACCIS  nodes — message  exchange.  E-mail,  exchange  of 
data  files,  and  exchange  and  access  of  database  data 

•  Interoperability  with  external  systems — message  exchange  and,  where  possible, 
exchange  of  data  files  with  information  systems  supporting  rapid  reaction  and  tactical 
forces,  with  other  NATO  and  national  systems,  and  with  civil  and  public  systems 

•  Common  applications — message  handling,  message  processing.  E-mail,  briefing 
support,  significant  event  handling,  tasker  handling,  document  handling,  data  views, 
map  graphics,  time  management,  and  office  automation 

•  Special  applications — mechanisms  are  to  be  defined. 

ACE  ACCIS  systems  are  expected  to  be  designed  and  implemented  from  a  common 
architecture,  including  a  common  set  of  standards  to  ensure  technical  interoperability  and 
portability  of  application  software — both  the  architecture  and  standards  follow  the 
recommendations  and  principles  of  the  NATO  Open  System  Environment  (OSE)  [Ref.  NATO  OSE 
1993].  Node  system  databases  are  to  be  based  on  common  data  definitions  to  ensure  operational 
interoperability;  common  data  will  be  defined  in  an  ACE  data  dictionary  and  maintained  by  an  ACE 
data  administration  capability.  ACE  ACCIS  will  follow  the  policy  provided  by  the  NATO  Data 


103  TOe  testbed  laboratory  is,  in  part,  an  outgrowth  of  an  ATCCIS  Testbed  developed  by  STC  in  support  of  the 
ATCCIS  Phase  II  program. 
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Management  Policy  [Ref.  NACISC  1993a],  NATO  Interoperability  Management  Plan  [Ref.  NIMP 
1988],  NATO  Interoperability  Planning  Document  [Ref.  NIPD  1993],  and  ACE  Security 
Directive  AD  70-1. 

The  ACE  ACCIS  adopts  the  NATO  OSE  Reference  Model,  which  is  identical  to  the  POSDC 
OSE  Reference  Model  (P1003.00  [Ref.  IEEE  1992]  and  which  is  shown  (with  some  additions  as  a 
third  “depth”  dimension)  in  Figure  1  provided  in  Chapter  1.  The  NATO  OSE  standards  applicable 
to  ACE  ACCIS  are  identified  in  Table  61. 104 

Table  61.  NATO  OSE  Standards  Applicable  for  ACE  ACCIS 


Source:  ACE  ACCIS  Terget  Architecture  [ACE  ACCIS  1 903c}. 

18.3  Air  Command  and  Control  System  (ACCS)195 

The  Air  Command  and  Control  System  (ACCS)  is  a  system  to  support  air  operations 
planning,  tasking,  and  execution  throughout  ACE  from  Major  NATO  Command  (MNC)  level  to 


104  Annex  B  of  the  ACE  ACCIS  Target  Architecture  [Ref.  ACE  ACCIS  1993c]  provides  detail  sod 
regarding  the  NATO  OSE  [Ref.  NATO  OSE  1993]  standards  applicable  to  ACE  ACCIS. 

105  Revised  Januvy  1994  based  on  [Rnddertwn  1994],  [Stewart  1994],  and  [NACMA  1993b]. 
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combat  unit  level.106  ACCS  will  interface  with  the  ACE  ACCIS  at  the  Principal  Subordinate 

Command  (PSC)  and  Allied  Tactical  Air  Force  (ATAF)  and  will  concentrate  on  new  development 

at  the  PSC  and  below.  ACCS  will  progressively  replace  a  current  federation  of  individual  systems  I 

that  support  ACCS  functions  to  varying  degrees.107  At  the  PSC  level  and  above,  ACCS  functions 

will  be  performed  by  the  ACCIS  of  each  Command. 

Development  of  ACCS,  which  integrates  offensive  and  defensive  air  command  and  control 
functions,  has  been  underway  for  several  years.  Implementation  is  planned  for  the  late  1990s.  In 
April  1989,  the  ACCS  Team  delivered  the  partially  completed  the  ACCS  Master  Plan.  The  ACCS  I 

Team  was  replaced  by  the  ACCS  Interim  Management  Group  and  later  by  the  NATO  Air 
Command  and  Control  System  Management  Agency  (NACMA).  NACMA  has  conducted  a 
system  definition  phase.  System  specifications  and  technical  estimates  were  prepared  in  1993  to 
support  subsequent  procurement  of  system  entities. 

Several  levels  of  operational  capability  (LOC)  are  being  defined  for  ACCS.  LOCI,  the  Erst  ( 

level  of  interoperability,  is  planned  for  the  1998  time  frame.  MIDS/Link  16  is  an  inherent  feature 
of  the  ACCS  design  and  may  be  incorporated  in  the  LOCI  implementation.  ACCS  will  use  Link 
16  for  ground-air-ground  tactical  data  exchange  communications  and  Link  21  [formerly  I  .ink  in 
Support  of  ACCS  (LISA);  also  formerly  Link  1  replacement]  for  ground-to-ground  bit-oriented 
data  exchange.  NACMA  is  coordinating  the  introduction  of  MIDS/Link  16  into  ACCS  and  has  ( 

initiated  a  study  on  the  operational,  technical,  and  financial  implications  of  the  implementation  of 
Link  16  in  ACCS.  [Ref.  Maes  1991] 

The  interoperability  concept  for  ACCS  is  discussed  in  Volume  IV,  Generic  Portion  of  the 
Overall  ACCS  Design,  of  the  ACCS  Master  Plan  [Ref.  ACCST  1986],  and  in  the  Supporting 
Document  on  Organization  Components  [Ref.  ACCST  1988].  ACCS  interoperability  is  planned  I 

through  exchange  of  information  through  commonly  agreed  information  definitions,  formats,  and 
technical  standards.  Where  possible,  the  standards  to  be  used  are  those  developed  by  the  Military 
Agency  for  Standardization  (MAS),  ADSIA,  and  TSGCE  SG9.  Specifically,  ACCS  will  be  based 
on  the  OSI  Reference  Model  as  specified  in  STANAG  4250  (NATO  Interoperability  Model),  the 
OSI  services  for  Layers  1  through  7  as  specified  in  ST AN  AGs  4251-4257,  and  the  OSI  protocols  i 

for  Layers  1  through  7  as  specified  in  STANAGs  4161-4267.  In  addition  to  the  ISO  Reference 
Model  standards,  the  NATO  Common  Interface  Standards  will  be  used.  TSGCE  SG9  is 
responsible  for  the  OSI  technical  standards,  and  ADSIA  is  responsible  for  the  procedural 
standards.  Operational  interoperability  standards  will  be  based,  in  part,  on  Allied  Tactical 
Publications  (ATPs).  i 

The  ACCS  communications  concept  is  to  integrate  the  various  NATO  and  national 
dedicated  communications  systems  currently  used  to  support  air  operations  into  a  common  user 
data  and  voice  network.  ACCS  would  be  hosted  on  the  existing  and  planned  communications 
without  ACCS-unique  communications  means.  Initially  a  packet  switched  data  communication 
overlay  would  be  added  to  the  circuit-switched  voice  system.  Continued  support  for  both  * 


106  The  seven  ACCS  major  functional  areas  are:  Force  Management  (FM),  C2  Resource  Management  (C2RM). 
Airspace  Management  (AM),  Surveillance  (S),  Air  Mission  Control  (AMC),  Air  Traffic  Control  (ATC),  and 
Information  Exchange. 

107  The  systems  include  Improved  United  Kingdom  Air  Defense  Ground  Environment  (IUKADGE),  Systeme  de 
Traitement  et  de  Representation  des  Informations  de  Defense  Aerienne  (STRIDA),  German  Air  Defense 
Ground  Environment  (GEADGE),  and  NATO  Air  Defence  Ground  Environment  (NADGE). 
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character-oriented  and  bit-oriented  messages  is  required.  Specifically,  use  of  tactical  data  link 
standards  such  as  Link  4,  Link  6,  Link  11,  Interim  JTIDS  Message  Standard  (UMS),  and  Link  16 
would  continue  through  the  foreseeable  future. 

ACCS  has  been  reviewing  technical  information  exchange  standards  and  requirements, 
including  the  need  to  replace  Link  1  for  data  exchange108  in  the  ground  environment  The  current 
approach  is  to  base  a  new  standard  on  STANAG  5516  (J-Series  messages)  and  to  develop  (within 
the  ADSIA  Data  Link  Working  Group)  new  or  modified  messages  to  fulfill  specific  ACCS 
Information  Exchange  Requirements.  ACCS  plans  to  use  a  military  version  of  X.25  for  packet- 
switched  systems  and  for  transfer  over  dedicated  circuits  and  through  circuit  switches.  Variable 
packet  lengths  are  desired.  CSMA/CD  and  token  ring  LANs  are  being  considered  for  ADP 
systems.  As  in  A7CCIS,  the  ACCS  database  concept  is  partitioned  and  partially  replicated.  An 
ACCS-wide  data  dictionary  is  planned.  Analysis  has  included  an  STC  investigation  on  the 
applicability  of  ASN.l  and  its  relation  to  the  syntax  of  STANAG  5500/ADatP-3  (FORMETS). 
There  is  a  concern  as  to  whether  use  of  FORMETS  would  permit  achieving  the  full  benefit  of  the 
OSI  model. 

The  following  considerations  in  ACCS  indicate  some  elements  of  the  technical  approach  for 
achieving  interoperability: 

•  A CCS  interfaces  will  be  required  to  the  following  generic  external  agencies/systems: 

NATO  intelligence  systems  (e.g.,  BICES,  NMOS) 

NATO  army  headquarters 

NATO  land-based  maritime  headquarters 

NATO  maritime  forces  afloat 

National  headquarters,  intelligence,  army  headquarters,  maritime  headquarters, 
territorial  commands,  meteorological  services,  civilian  air  traffic  control,  and  local 
authorities. 

•  Requirements  have  been  identified  for  free  text  traffic  (electronic  mail),  graphics,  and 
facsimile  transmission  services.  Video  transmission  is  a  potential  long-term 
requirement  for  ACCS,  but  it  has  been  excluded  from  consideration  for  the  current 
ACCS  planning  time  frame  (1990s). 

•  Two  ADSIA  standardization  documents  have  been  considered  important  for  ACCS  in 
the  area  of  formatted  messages: 

ADatP-3/STANAG  5500,  containing  a  catalogue  of  character-oriented  formatted 
messages 

Common  Information  Exchange  Glossary  (CIEG),  containing  terms  and 
definitions  applicable  to  the  development  of  both  bit-  and  character-oriented 
procedural  standards. 

•  ACCS  requires  an  electronic  mail  service.  The  planned  standard  is  the  Military 
Message  Handling  System,  based  on  ITU-TS  X.400. 

•  ACCS  further  requires  automated  interactions  between  databases  (e.g.,  updates)  that 
could  be  event  driven.  The  FT AM  standard  has  been  recommended  for  consideration 
for  ACCS  use,  particularly  for  bulk  update  of  databases. 

•  The  functions  (e.g.,  syntax  and  formatting  rules)  of  ASN.l  and  the  associated  Basic 
Encoding  Rules  (BER)  were  recognized  by  the  ACCS  Team  as  potentially  richer  and 
offering  greater  scope  than  NATO  Message  Text  Formatting  System  (FORMETS) 


108  The  ADSIA  Data  Link  Working  Group  (DLWG)  has  been  given  a  Priority  One  task  to  develop  a  link  1 
replacement;  ADSIA  DLWG  has  asked  TSGCE(SG9)  to  look  at  media- independent  protocols  for  such  a 
cooccpt 
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functions  of  ADatP-3/STANAG  5500.  Large  investments  in  FORMETS  are  being 
made  in  operational  systems,  and  NATO  interoperability  continues  to  be  based  on 
FORMETS  and  ADatP-3.  Eventually,  however,  FORMETS  could  be  replaced  by  ISO 
standards  for  automated  data  exchange  to  make  better  use  of  the  functionality  of  the 
OSI  model  and  the  richness  of  ISO  standards.  There  are  potential  problems  in 
ensuring  interoperability  between  systems  using  FORMETS  and  systems  using  ISO 
standards.  Investigation  is  needed  on  whether  the  use  of  an  information  structure 
based  mt  ADatP-3  message  contents  is  a  sufficient  basis  for  achieving  backwards 
interoperability  with  FORMETS  systems. 

•  ACCS  anticipates  the  use  of  gateways  for  data  forwarding  (message  standard 
translation),  trusted  secure  interfaces  bkween  cooperating  ADP  systems  to  control 
access  to  data,  and  physical  interconnection  of  different  communication  systems. 

•  A  connection-oriented  virtual  call  protocol  has  been  proposed  for  ACCS,  rather  than  a 
connectionless  (or  datagram)  protocol,  as  the  basis  for  packet  switched  services. 
Virtual  call  services  are  widely  used  in  civil  networks;  they  can  result  in  more  efficient 
transmission  because  of  significantly  lower  packet  overheads,  and  they  can  simplify 
network  management  An  issue  is  whether  virtual  call  would  provide  adequate  flow 
control  under  stress  conditions.  Limited  use  of  a  connectionless  service  may  also  be 
required. 

In  June  1993,  NACMA  developed  a  set  of  views  on  portability,  defined  in  NATO  as  “the 
ability  of  a  component  to  operate  with  identical  functionality  in  dissimilar  environments,”  or,  in 
other  words,  as  a  software  quality  factor  expressing  the  ease  with  which  software  products  may  be 
transferred  to  various  hardware  and  software  environments.  The  concerns  are  with  the  constraints 
on  ACCS  software  architecture  and  standards,  portability  testing  and  verification,  cost,  and 
guidelines  and  methods  to  ensure  achievement  of  portability.  One  issue  is  whether  the  boundary  of 
portable  software  should  be  at  the  level  of  general-purpose  software  (so  that  the  human-machine 
interface  or  information  exchange  interface  is  portable  on  many  different  operating  systems)  or  at 
die  application/application  support  software  level  (so  that  applications  are  expected  to  run  under 
different  operating  systems  for  many  hardware  platforms,  relying  on  services  offered  by  general- 
purpose  software).  These  groups  of  software  are  shown  as  layers  in  the  A CCS  System 
Architecture  (Figure  23).  The  term  THN  refers  to  the  territorial  host  nation.  [Ref. 
NACMA  1993a;  Vicini  1994] 

The  ACCS  software  architecture  has  the  following  elements  of  application  support 
software:  simulation,  exercise,  training,  generalized  monitor,  data  analysis,  and  diagnostics.  The 
major  ACCS  functions  and  elements  of  application  software  are  the  following  [Ref. 
NACMA  1992, 1993a,  and  1993b]: 

•  Force  management  (FM) — planning,  tasking,  and  weapjn/mission  preparation  with 
die  goal  of  timely  and  effective  C2  for  the  employment  of  air  resources.  ADP  support 
is  provided  to  facilitate  force  employment,  option  generation,  and  evolution. 
Weapon/mission  preparation  involves  performance  of  air  base,  surface-to-air  missile 
(SAM),  and  short-range  air  defense  (SHORAD)  management,  as  well  as  basic  mission 
planning  and  dissemination  of  appropriate  orders. 

•  Command  and  control  resources  management  (C2RM) — comprises  activities 
associated  with  the  employment  and  use  of  the  ACCS  resources,  including  their 
disposition,  availability,  and  direct  logistic  support.  Resources  include  equipment 
such  as  sensors,  communications,  and  ADP,  as  well  as  personnel  and  supporting 
services.  The  goal  of  C2RM  is  to  enable  the  commander  to  continuously  evaluate  the 
C2  situation  in  order  to  plan,  implement,  and  control  all  arrangements  required  to 
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support  operations  of  own  assets  in  real  time  and  minimize  interference  between  own 
C2  resources. 

•  Airspace  Management  (ASM) — plans,  implements,  and  manages  the  use  of  airspace  to 
ensure  maximum  freedom  and  minimum  risk  to  own  air  assets. 

•  Air  Mission  Control  (AMC) — directs  offensive,  defensive,  or  support  missions  to 
accomplish  objectives.  It  includes  threat  warning  and  avoidance,  vectoring  for 
refueling  operations  or  target  attack,  and  safe  passage  through  defended  friendly 
airspace.  An  unambiguous  air  picture  (recognized  air  picture  or  RAP)  is  necessary  for 
performing  this  function. 

•  Air  Traffic  Control  (A7C) — plans  and  controls  the  use  of  airspace,  including  the 
processes  involved  in  maximizing  traffic  flow  (military  and  civil)  while  ensuring  safe 
separation  and  minimizing  interference  to  friendly  air  operations. 

•  Surveillance— detects,  tracks,  and  identifies  air  objects  in  each  area  of  responsibility 
and  compiles  the  RAP. 
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Figure  23.  ACCS  System  Architecture 

To  provide  a  standard  framework  and  ensure  portability,  NACMA  intends  to  pro\ide  a  set 
of  standard  profiles — suites  of  base  standards  together  with  identification  of  chosen  classes, 
subsets,  options,  and  parameters  for  the  base  standards — to  its  bidders.  The  framework 
recommended  for  these  profiles  is  the  POSEX  Open  System  Environment  (OSE)  Reference  Model 
(P1003.0)  [Ref.  IEEE  1992],  which  is  a  conceptual  framework  that  provides  a  context  for  user 
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requirements  and  standards  specification  and  a  set  of  information  system  building  blocks  with 
associated  interfaces,  services,  protocols,  and  data  formats.  NACMA  is  also  incorporating  into  its 
recommendations  the  guidance  provided  by  the  Ada  Implementation  Subgroup  (AISG)  of  the 
NACISC’s  Information  System  Working  Group  (ISWG)  on  the  NATO  OSE  Reference  Model, 
September  1993,  and  the  ISWG  Software  Standards  Study.  The  draft  recommendations  include 
use  of  a  POSIX-compliant  operating  system,  Ada,  SWL,  and  OSF/Motif.  The  recommendations 
also  address  application  programming  interfaces  (APIs)  as  described  in  the  POSIX  OSE. 
[NACMA  1993a;  Vicini  1994] 

18.4  Battlefield  Information  Collection  and  Exploitation  Systems  (BICES) 

The  Battlefield  Information  Collection  and  Exploitation  Systems  (BICES)  will  provide 
intelligence  support  to  NATO  commanders.  Initially,  BICES  was  to  be  a  homogeneous  system  in 
all  NATO  nations  and  ACE  headquarters  to  cover  Warsaw  Pact  surface  forces  and  activities. 
BICES  today  will  be  heterogeneous  national  systems  that  are  interoperable  through  agreed  NATO 
standards  for  cooperative  intelligence  in  all  areas  for  own  nation,  multinational  coalitions,  and 
NATO  in  peace,  crisis,  and  war.  From  the  beginning,  BICES  has  consisted  of  the  following  three 
segments  [SHAPE  1994]: 

•  Higher  national  segment  [Chairman  of  Defense  (CHOD)/MOD  national  intelligence 
centers  and  sources] 

•  NATO  segment  (NATO  commands  in  ACE) 

•  Lower  national  segment  [combat  forces  and  systems  below  the  principal  subordinate 
command  (PSC)  level]. 

The  BICES  Team  was  formed  to  focus  on  national  segments  for  BICES.  The  BICES 
Team  will  create  tailored,  unique,  and  specific  options  and  recommendations  for  each  nation  in 
national  portfolios.  The  BICES  Pilot  Study  (BPS)  focuses  specifically  on  the  NATO  segment  of 
BICES  and  the  provision  of  BICES  capabilities  as  an  integrated  element  of  the  ACE  ACCIS. 
Results  of  the  BPS  are  due  in  1993  and  will  contain  recommendations  for  a  near-term  solution — 
termed  the  Evolutionary  BICES  Capability  (pre-ACE  ACCIS) — as  well  as  integration  into  ACE 
ACCIS.  User  requirements  for  the  ACE  segment  of  BICES  are  completed:  ACE  Intelligence 
Baselines,  1990;  and  BICES  Baseline  Document,  1992.  Two  national  gateways  have  been 
designated  as  part  of  BICES:  the  US  Linked  Operations-Intelligence  Centos  Europe  (LOCE,  also 
known  as  Limited  Operational  Capability-Europe)  and  the  German  Joint  Analysis  System  Military 
Intelligence  (JASMIN). 

Among  the  approaches  being  considered  for  BICES  are  a  common  database  and  a  data 
dictionary,  whose  scope  and  content  are  to  be  determined.  NATO  OSI  standards  from  ISO  and 
ITU-TS  will  be  used  unless  they  cannot  meet  the  BICES  requirements.  BICES  must  also  conform 
to  the  NA  TO  TCIS  Transition  Strategy. 

The  BICES  evolutionary  test  environment  (BETE)  is  being  developed  during  1993-1997. 
An  initial  step  is  specification  of  a  common  LAN  to  provide  connectivity  among  the  nations. 
Provisions  in  the  LAN  standards  are  being  made  for  such  interfaces  as  PC-type  asynchronous, 
TCP/IP,  circuit-switched  or  packet-switched  data  networks,  and  X.25.  In  some  cases  a  CISCO 
router  will  be  used.  Both  the  User  Agent  and  Mail  Gateway  (CC:MAIL/X.400)  and  the  X.400 
Message  Transfer  Agent  and  Mail  Gateway  (X.400/SMTP)  will  be  available.  Database  exchanges 
will  initially  be  indirect  exchanges  using  message  or  file  transfer.  Message  exchange  may  be  by 
electronic  mail  (unformatted  messages)  or  AD  80-50  formatted  messages.  Initially,  X.400: 1988 
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will  be  adopted.  Eventually,  ADatP-3  message  exchange  (1995)  and  X.400-.1992  (1997)  will  be 
supported.  Graphics,  imagery,  and  other  information  transfers  will  be  supported  by  several  types 
of  file  exchange:  FT AM,  FTP,  CC:MAIL,  or  X.400.  In  the  latter  pan  of  the  evolutionary 
development  proposed  by  the  BICES  Team  for  national  system  interoperability,  direct  database 
exchange  is  planned  (the  database  standards  have  not  been  selected  but  may  include  SQL,  RDA, 
and  TP).  While  the  early  BICES  capabilities  suppon  limited  on-line  data  exchange  during 
exercises  and  message/file  exchange  within  a  heterogeneous  environment,  the  evolution  will  be 
toward  indirect  data  exchange  between  heterogeneous  intelligence  database  systems  and  finally 
supporting  interactive  data  exchange  within  the  BICES  distributed  intelligence  database  system. 
[Ref.  SHAPE  1994] 

A  December  1993  paper  [Lambert  1993]  by  the  BICES  Team  noted  a  number  of  data 
modelling  activities  related  to  intelligence.  STC  has  completed  the  draft  of  a  three-volume  report 
(STC  TN  443)  on  the  ACE  Data  Model  Volume  I  contains  the  initial  data  model  developed  by  the 
ACE  SD&IC;  Volume  II  provides  detailed  descriptions  of  intelligence  resource  requirements 
(primarily  orders  of  battle)  from  ACE  source  documents;  and  Volume  HI  describes  die  logical 
structure,  data  elements,  keys,  and  domains  for  the  ACE  Data  Model.  This  work  was  conducted  in 
support  of  BPS  and  provided  to  the  BPS  contractor  for  further  data  modelling  work.  In  a  related 
STC  effort,  an  investigation  was  conducted  to  explore  alternative  approaches  to  database-to- 
database  transfer  by  bulk  load  and  batch  updates,  and  a  common  information  transfer  format  (TTF) 
was  recommended.  Hie  concept  was  that  each  nation  would  be  responsible  for  translation  between 
the  nation’s  internal  transaction  format  at  the  ITF.  The  next  step  in  this  investigation  would  be 
prototyping.  Finally,  the  BICES  contractor  (BICOM)  is  developing  logical  models  for  both  the 
evolutionary  BICES  capability  (EBC)  and  the  ACE  ACCIS  BICES  capability  (ABC).  This  work 
is  based  on  the  earlier  work  conducted  at  STC  and  uses  the  Structured  Analysis,  Design,  and 
Implementation  of  Information  Systems  (STRADIS)  methodology  and  associated  tools.  An  initial 
draft  of  the  logical  models  was  planned  for  early  1994.  [Ref.  Lambert  1994] 

In  January  1994,  the  BICES  Team  completed  a  draft  Functional  Area  Analysis 
Interoperability  [Ref.  BICES  1994].  This  document  recommends  a  standards  framework  based  on 
the  POSIX  OSE  Reference  Model  (P1003.0)  [Ref.  IEEE  1992]  and  an  initial  set  of  information 
system  standards.  The  standards  address  the  following  types  of  information  exchange  (termed 
information  object  types)  [Ref.  Lambert  1994]: 

•  Formatted  message  (e.g.,  ADatP-3  messages) 

•  Unstructured  text  (e.g.,  AD  80-50,  human  intelligence  reports,  intelligence  briefings) 

•  Formatted  data  (e.g.,  database  retrievals,  bulk  database  loads,  batch  updates, 
spreadsheet  data) 

•  Graphics  (e.g.,  map  overlays) 

•  Geographical  information  system  data  (e.g,  terrain  data,  traffic  data) 

•  Imagery  [e.g.,  magazine-quality  imagery,  including  stored-video  camera  (SVC) 
images) 

•  Compound  objects  (e.g.,  mixed-media  documents  with  text  and  graphics) 

•  Digital  voice  (e.g.,  briefings,  intelligence  situation  reports) 

•  Video  [e.g.,  video  teleconferencing  (VTC),  reconnaissance  films]. 

These  requirements  may  be  addressed  in  four  ways.  An  information  distribution  mode 
provides  for  the  transfer  of  information  from  a  source  system  to  one  or  more  destination  systems. 


Chapter  18 


405 

UNCLASSIFIED 


NATO  Initiatives 


UNCLASSIFIED 


performed  on  a  scheduled  or  periodic  basis  or  the  occurrence  of  some  external  event  A  stimulated 
information  transfer  involves  an  interaction  between  the  source  system  and  a  single  destination 
system,  in  which  the  destination  system  initiates  the  interaction.  The  query-response  transaction 
mode  allows  a  user  to  perform  on-line,  interactive  access  to  information  stored  in  a  database;  the 
information  may  be  structured  or  unstructured  (e.g.,  a  text  file).  Finally,  the  informal  exchange 
supports  transactions  between  users  that  has  no  direct  effect  on  stored  information  (e.g.,  electronic 
mail,  voice  mail). 

A  BICES  Reference  Model  has  been  developed  with  platform  services  aligned  with  the 
POSIX  OSE  Reference  Model.  The  applicable  services  and  standards  are  defined  in  three  forms: 
recommended  (an  international  standard  and  an  adequate  number  of  COTS  products  exist); 
emerging  (de  jure  national,  regional,  or  draft  international  standards);  and  interim  (de  facto 
standards  from  academia  or  industry  widely  adopted  and  available  in  COTS  products).  The 
framework  of  the  BICES  Reference  Model  and  the  initial  draft  of  the  recommended  standards  is 
provided  in  Table  62.  It  should  be  noted  that  this  early  draft  requires  refinement,  further  market 
analysis,  experimentation  (e.g.,  BETE  Tests  1.1  and  1.2  in  1994)  and  coordination  with  the 
nations  before  becoming  stable.  It  is  presented  to  show  the  breadth  of  standards  identified  for 
BICES. 

18.5  NATO  Maritime  Operational  Intelligence  Support  (NMOS) 

The  NATO  Maritime  Operational  Intelligence  Support  (NMOS)  will  also  provide 
intelligence  support  for  the  ACE  ACCIS.  NMOS  provides  the  naval  surface  and  subsurface 
picture  for  NATO.  NMOS  is  a  joint  project  under  SACLANT  and  SHAPE.  The  only  standards 
identified  for  NMOS  that  are  not  part  of  the  NATO  Common  Interface  Standards  are  additional 
STANAG  5500  (ADatP-3)  messages  [Ref.  NMICC  1989J.  The  Military  Committee  approved  the 
Tri-MNC  concept  for  NMOS  early  in  1987.  [Ref.  NATO  MC  1987] 

18.6  Quadrilateral  Interoperability  Programme  (QIP) 

The  Quadrilateral  Interoperability  Programme  is  an  initiative  originally  of  four 
nations — France,  Germany,  United  Kingdom,  and  United  States — to  develop  and  implement,  for 
the  short  term,  an  interface  through  which  the  four  national  tactical  land  ACCISs  [respectively, 
Systeme  Informatique  de  Commandement  des  Forces  Terrestres109  (SICF),  Heeres- 
Fuehrungsinformationssystem  fur  die  rechnergestuetzte  Opera tions-fuehrung  in  Staeben110 
(HEROS),  WAVELL,  and  Maneuver  Control  System  (MCS)]  can  interoperate.  Software 
development  for  the  national  systems  has  been  completed,  and  an  interoperability  demonstration 
was  successfully  conducted  in  May  1990  near  Ingolstadt,  Germany.  [Ref.  ADSIA  1988a] 
Meetings  were  held  in  June  and  July  of  1990  to  explore  options  for  fielding  initiatives  based  on  the 
Quadrilateral  Interoperability  Programme  standards.  Italy  has  recently  joined  the  QIP,  using  its 
STACCON  army  tactical  CCIS. 


109  Information  System  for  Command  of  Ground  Forces  (SICF),  France. 

HO  Army  Command  and  Control  Information  System  for  the  Computer  Assisted  Conduct  of  Operations  within 
Stalls  (HEROS),  Germany. 
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Table  <2.  BICES  Reference  Model  and  Information  System  Standards 


System  Service  Arses 

Interim  Stenderds 

Emerging  Standards 
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Table  82.  (Cont’d) 


chatter  dbvet  terminal-UMr  to  tefminal-UMr  convareation. 


(2)  Data  transformation:  transforms  source  data  («.g.,  text,  graphics,  photographs,  images,  analog  data) 
into  (tigltai  data  that  can  bs  processed  try  the  computer. 

(3)  Data  analysis:  supports  functions  such  as  Rnaar  analysis,  regression  analysis,  curve  fitting,  and  trend 
analysis. 

(4)  Inductee  Window  Manager,  TooMt,  and  Style  Guide;  excludes  Window  System. 

Requirements.  The  Quadrilateral  Tactical  Interface  Requirements  (QTIR)  document 
[Ref.  QIC  1988]  expresses  the  basic  requirements.  Hie  Quadrilateral  Technical  Interface  Design 
Plan  (QITDP)  [Ref.  QIC  1988a]  specifies,  for  the  gateway,  the  technical  interface  based  on  the 
ISO/ITU-TS  OSI  Reference  Model.  The  operational  requirements  specify  for  information 
representation  die  use  of  formatted  messages  as  described  in  STANAG  5621  Edition  2  and  in 
accordance  with  ADatP-3  (STANAG  5500)  specifications.  The  specifications  for  the  common 
international  interface  between  national  gateways  are  provided  in  the  QTIDP  by  annexes  describing 
each  of  the  seven  layers  with  options  and  parameters  derived  from  ISO/ITU-TS  standards  in  order 
to  meet  the  specific  military  requirements  (e.g.,  naming,  addressing,  priority,  sensitivity,  size  of 
messages,  and  segmenting). 

Management.  The  December  1993  Quadrilateral  Interoperability  Programme 
Management  Plan  (QIPMP)  [Ref.  QIPMP  1993]  provides  management  guidance  for  the  QIP, 
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dftrjrihei  the  management  nrgini  ration  and  procedures,  and  defines  national  responsibilities  The 
QIPMP  identifies  die  following  organization  units  for  executing  the  QIP  Programme  and  their 
roles: 


fkttdrHatwl  Interface  fenwriafiny  of  the  program  manaywra  of  the  narinnal 

CCISs  participating  in  the  QIP) — defining  orcrall  strategy  for  the  program  and  making 
similar  policy  decisions;  resolving  decisions  on  issues  passed  from  other  boards;  and 
developing  the  QIPMP 

Configuration  Control  Board  (CCB) — drafting  the  Quadrilateral  Configuration 
Management  Plan  (QCMP);  and  maintaining  all  QIP  documentation  in  accordance  with 
the  configuration  control  procedures  of  the  QCMP 

Planning  and  Execution  Board  (PEB)— planning  and  coordinating  the  program 
development  schedule  with  the  program  test/field  evaluation  schedule;  managing 
program  execution;  conducting  tests,  demonstrations,  and  exorcises  as  required; 
collecting  and  publishing  test  data;  and  drafting  die  Quadrilateral  Test  and  Evaluation 
Master  Plan. 


•  Operational  Working  Group— providing  tactical  and  operational  advice  to  other 
woriring  groups  and  boards  as  required;  proposing  information  exchange  requirements 
(IERs)  for  C2  of  multinational  formations  on  die  basis  of  NATO  interoperability 
standards;  evaluating  message  text  formats  used  by  the  QIP  from  a  tactical  point  of 
view;  and  evaluating  and  further  developing  employment  concepts  for  a  QIP  gateway 

•  Procedure  Woriring  Grnun — providing  advice  and  content  of  NATO  named  memagea 
and  procedures  for  implementation  of  operational  requirements  concerning  deployment 
and  operation  of  gateways;  analyzing  NATO  procedural  interoperability  standards 
designated  to  be  used  in  die  QIP;  specifying  and  clarifying  open  details  to  achieve 
common  implementation;  and  identifying  necessary  changes  to  NATO  procedural 
interoperability  standards  and  preparing  change  proposals  to  ADSIA  and/or  the 
Military  Agency  for  Standardization. 

•  Exercise  Coordinators  Woriring  Group — preparing  exercise  plans;  managing  and 
coordinating  pre-exercise  activities;  conducting  die  exercises;  collecting  and  analyzing 
exercise  data;  and  preparing  an  Exercise  Report 


Standards  and  Profiles.  Standards  specified  in  the  QTIDP  are  identified  in  Table  63. 
Specifications  of  Layers  1  through  5  are  closely  related  to  ISO  standards.  Layer  6  (presentation)  is 
a  null  layer.  Layer  7  specifies  message  handling  functionality  based  on  the  ITU-TS  X.400  (MHS- 
84)  standards  for  die  subset  of  service  elements  provided  by  the  PI  and  P2  protocols  and  the 
service  elements  provided  by  Reliable  Transfer  Service  (RTS),  as  defined  by  ISO  9066-2,  and 
integrated  with  the  Association  Control  Service  Element  (ACSE,  ISO  8649  and  ISO  8650)  that 
provide  support  for  other  application  entities.  The  QTDMP  [Ref.  QIC  1988b]  specifies  a  plan  for 
interface  testing  and  interoperability  testing  before  performing  die  1990  demonstration.  Most  of 
the  interoperability  parameters  are  specified  by  the  options,  classes,  and  system  parameters  selected 
from  ISO/rrU-TS  standards;  some  of  the  other  interoperability  parameters  are  defined  in 
accordance  with  military  requirements  defined  for  messages  in  the  QTIR. 


A  preliminary  review  has  shown  that  all  standards,  stacks,  and  options  for  die  Quadrilateral 
Interoperability  Programme  that  are  also  relevant  to  ATCCIS  have  been  identified  in  earlier 
chapters  of  this  working  paper.  In  addition,  a  separate  analysis  [Ref.  Ford  1987]  has  been 
performed  that  identifies  a  large  number  of  interoperability  parameters  and  provides  their  values. 
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18.7  Standard  Automated  Menace  Interface  for  NATO'*  ACCISe  (STAMINA) 

This  summarizes  the  results  of  a  review  of  the  specifications  for  STAMINA. 
[Re£  NACISA 1988]  STAMINA  is  being  developed  by  an  Interface  Woridng  Group  of  NATO 
Communications  and  Information  Systems  Agency  (NACISA)  to  be  used  as  a  standard  interface 
for  passing  information  among  ACC3S&.  Initial  demonstrations  are  plannedfor  the  Central  Region 
ACCIS  and  three  target  systems:  the  Allied  Command  Baltic  Approaches  Command  and  Control 
Information  System  (ACBA  CCIS),  the  Central  Region  Alternate  War  Headquarters  CCIS  (CR 
AWHQ  CCIS).  and  die  Allied  Tactical  Operations  Centre  CCIS  (ATOC  CCIS.  also  known  as  the 
BIPUL  Follow-On).  STAMINA  is  planned  to  be  used  for  such  interfaces  as  [Ref.  STAMINA 
1990a]: 

•  Central  Region  (CR)  ACCIS  to  UKAIR  ACCIS  and  to  EIFEL  (ATOC) 

•  SHAPE  to  CR  Primary  War  Headquarters  (HQ)  and  to  CR  Alternative  War  HQ 
(AWHQ) 

•  ACBA  COS  to  CR  ACCIS  and  to  EIFEL  (ATOC). 

•  Various  interfaces  at  SHAPE  HQ. 

STAMINA  now  consists  of  two  separate  transport  profiles  and  an  X.400-oriented 
application  profile.  The  transport  profiles  support  (1)  XJ25  packet  switched  networks  for  use  in 
CR  ACE  and  (2)  permanent  analog  circuits  for  point-to-point  interfaces  using  dedicated  analog 
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circuits.  (A  third  transport  profile,  switched  analog  circuits  for  use  with  the  NATO  IVSN  analog 
voice  network,  has  recently  been  deleted,  as  there  have  been  no  interest  shown  in  implementing 
this  aspect  of  STAMINA.) 

The  entire  STAMINA  profile  for  MHS-84  has  been  adopted  by  TSGCE  SG9  as  an 
intercept  profile  for  the  NTIS  Transition  Strategy.  [Ref.  TSGCE  1989d] 

Requirements  for  the  Quadrilateral  Interoperability  Programme  and  STAMINA  overlap,  but 
it  is  not  clear  at  this  time  if  they  will  converge.  Generally,  STAMINA  attempts  to  provide  military 
features  (e.g.,  four  levels  of  precedence  and  NATO  classifications)  as  ‘extensions"  in  Layer  7.111 
Further,  STAMINA  provides  three  transport  protocols^using  Class  0  and  Class  2),  whereas  the 
QTTDP  provides  just  one  (using  Class  2).  [Ref.  ADSIA  1988a] 

18.7.1  STAMINA  Application  Profile  ; 

The  STAMINA  Version  4  application  profile  for  message  handling  is  *  modification  of 
ITU-TS  X.400(MHS>-1984.  Eighteen  military  features  were  added;  these  features  are  identified  in 
Table  64.  STAMINA  messages  are  free  text  and  text  formatted  according  to  die  ADatP-3 
specification.  [Ref.  ADatP-3 1986a] 


Tibia  84.  MMtary  Faaturae  Added  to  the  STAMINA  Specification 


Description 

1. 

cxssinovcx  isimonanon  mo 

Dale  and  time  otRcMty  authorized 

2. 

Sublet  indcator  Code 

tyi  suofoci  coon  ror  (MuVMiion  wommon 

3. 

Primoiy  Procodonco 

Grades  of  delivery  (e.g..  urgent,  normal)  for  primary 

- i_t  _ 

rvcpsrv 

4. 

Copy  Pracodonco 

Qredee  of  dofivoiy  for  copy  recipient 

5. 

Security  Cla— Mlcation 

Rve  cjeaaUcrttena  (o*..  NATO  UNCLASSIFIED) 

8. 

Security  Category 

Ep.  ATOMAL,  EYES  ONLY 

!  7. 

unpnBui  iqononif 

OrigbiaNng  organisational  unft  measage  reference 

8. 

Address  List  hMflcation 

Address  Hat  type  and  identifier;  on  origination  conveys 
mun-a*tana*on  obowji  on  nosipi  lonMVQRiQ  soNn 

8. 

Cteer  Inctc  eSon 

TrwwmMed  vthoul  any  security  dssslicslion 

10. 

Codrees  Message  Indteator 

jnrjcaMe  a  codre—  encrypted  mseeaps 

11. 

Correction* 

Conectione  are  required  in  body  of  tsod 

12. 

Exempted  Addrses 

Exomptod  namo(s)  from  accomponying  addrets  M 

13. 

HsndnQ  Instructions 

Handfog  Iftrtutiflni  aocompany  thi  fnmsQi 

14. 

Message  inabuetions 

MtttoQt  inttniedont  acronnpany  tho  momapt  * 

16. 

Message  Type 

DMnguMi  botwoon  normal  and  axord**  traffic 

16. 

Othor  Rodpiont  Incicdof 

identifiee  other  recipient(e)  also  intended  to  receive 

17. 

m  ronrarooa 

Ueed  in  fonsening  a  message 

18. 

Socurty  PoHcy  ktantiffor . 

Identifies  a  security  poNcy 

lit  STAMINA  team  the  rn—rrrlal  Plead  P2 i 

i  to  P2;  *e  QnDP  redefines  bo*  PI  red  Pi 


1  defines  new  service* 
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The  application  profile  has  two  types  of  user  access: 

•  Private  Message  Handling  Service  (MHS)  Access:  UA  and  MTA,  Private 
Management  Domain  (PRMD)  to  PRMD,  A/3211  (based112  on  ITU-TS  X.400-1984 
and  ISO  8327) 

•  Military  Private  MHS  Access:  UA  and  MTA,  PRMD  to  PRMD,  A/321 1(M)  (based  on 
ITU-TS  X.400-1984,  ISO  8327,  ACP  117,  and  ACP 127). 

The  A/3211  application  profile  is  the  X.400  MHS,  in  which  the  Application  Layer  (Layer  7)  has 
three  sublayers:  User  Agent  Layer  defined  by  X.420,  Message  Transfer  Layer  defined  by  X.41 1, 
and  Reliable  Transfer  Server  defined  by  X.410.  The  A/3211  Presentation  Layer  (Layer  6)  is 
defined  by  ISO  8823  (based  on  X.410),  and  the  Session  Layer  (Layer  5)  is  defined  by  ISO  8327 
(based  on  X.410). 

STAMINA  applications  profile  and  the  Quadrilateral  Profile  (QP)  are  both  military  versions 
of  ITU-TS  X.400(MHS>1984.  The  QP  is  being  developed  and  used  by  four  command  and 
control  system  programs  in  PR,  GE,  UK  and  US.  The  QP  has  a  angle  transport  profile  based  on 
X.25.  To  understand  some  of  the  essential  differences  between  STAMINA  and  QP,  note  that 
Layer  7  of  X.400-1984  consists  of  die  User  Agent  (UA),  the  Message  Transfer  Agent  (MTA),  and 
die  Reliable  Transfer  Agent  (RTA).  The  RTA  serves  as  the  liaison  with  the  Session  Layer 
protocols  (in  X.400-1984,  the  Presentation  Layer  is  a  null  layer,  i.e.,  there  is  no  layer  6,  so  Layer 
7  liaises  directly  with  Layer  3).  Both  die  UA  and  MTA  use  peer  (e.g.,  UA-to-UA)  protocols  to 
communicate  to  distant  UAs  and  MTAs.  The  peer  protocol  for  the  UA  is  the  Interpersonal 
Messaging  Protocol  (P2),  while  the  peer  protocol  for  MTA-to-MTA  communication  is  the  Message 
Transfer  Protocol  (PI).  Thus,  PI  defines  the  relaying  of  messages  among  MTAs,  while  P2 
defines  the  service  elements  of  the  interpersonal  messages  exchanged  by  UAs.  The  STAMINA 
profile  provides  military  features  by  extending  P2  (using  a  "superset"  approach),  permitting  these 
features  to  be  mapped  into  similar  commercial  features  in  the  PI  protocol  without  affecting  lower 
layer  protocols,  whereas  the  QP  changed  both  PI  and  P2  in  such  a  way  that  the  changes  affected 
aervioes  in  lower  protocol  layers  as  well. 

18.7.2  STAMINA  Transport  Profiles 

STAMINA  includes  selection  of  ITU-TS  and  ISO  standards — along  with  allowable  options 
and  parameters — necessary  to  attain  interoperability  among  the  end  systems.  STAMINA  is  baaed 
on  profiles  defined  in  the  SPAG  User's  Guide.  [Ref.  SPAG  1987]  The  STAMINA  transport 
profiles  are: 

•  Permanent  Telephonic  Circuit  Providing  Connection-Oriented  Network  Service, 
T/21(M) 

•  Telephonic  Switched  Circuits  Providing  Connection-Oriented  Network  Service, 
T/22(M) 

•  Permanent  Access  to  Packet  Switched  Data  Network  (PSDN),  OSI  Connection-Mode 
Services,  T/312(M) 

Table  63  identifies  the  standards  specified  for  the  STAMINA  transport  profiles.  The  current 
standard  for  STAMINA  is  Version  4.0,  April  1990.  [Ref.  STAMINA  1990] 


112  STAMINA  Version  3.0  [Ref.  27]  also  ches  "ISO  8322*  forT/3211  md  T/321KM),  bat  ibis  strtvd  does  not 
exist 
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Table  65.  Standard*  far  STAMINA  Tranaport  ProlWaa 


YvMMpQft  PfOflbl 

Layar 

T/21(M) 

T/22(M) 

T/312(M) 

T/312, 

- 

4.  Transport 

ISO  8072 

ISO  8072 

ISO  8072 

ISO  8073* 

ISO  8073* 

ISO  8073* 

«  - «. 

A  N8lwutK 

ISO  8348 

ISO  8348 

ISO  8348 

ISO  8208 

ISO  8206 

ISO  8208 

ISO  8878 

ISO  8878 

ISO  8878 

STANAG  4214 

STANAG  4214 

STANAG  4214 

STANAG  5048 

STANAG  5048 

STANAG  5048 

mJ-TS  V.25 
UU-TS  V.25bw 

2.  Data  Link 

ISO  7776^ 

ISO  7778b 

ISO  7776^ 

rru-TS  V2s 
mj-TS  V.25b« 

1.  Physical 

rru-TS  V24 

ITU-TS  V.24 

rru-TS  X21 

rru-TS  v.ii 

rm-Tsv.ii 

ITU-TS  V.11 

ISO  2110 

ISO  21 10 

ISO  2110 

ISO  4802 

rru-TS  v^s 

ISO  4902 

ITU-TS  V.25b« 

ISO  4903 

MH.-STD-188C 

MU.-STD-188C 

MU.-STD-188C 

* 

ITU-TS  X21  bis 

*  Class  0  (Simple)  and  Class.2  (Multiplexing)  an  mandatory;  Clan  4  (Error  Detection  and 

Recovery )  is  optionaL 

**  Options  2  and  8  of  ISO  7809  (Balancad  Asynchronous  Clan)  an  mandatory;  Option  10 

may  be  included  under  bilateral  agreement 

18.7.3  STAMINA  Development  Activities 

One  current  activity  is  addressing  the  need  to  add  functionality  required  to  support  relays 
between  X.400  and  ACP-127  message  domains,  as  recommended  by  TSGCE  and  recommended 
by  the  NATO  C3  Architecture  and  the  NATO  C3  Master  Plan.  In  addition,  STAMINA  is  building 
a  database  of  die  interoperability  parameters  (e.g.,  speeds  for  communications  lines)  chosen  by 
implementors  of  STAMINA  specifications.  Some  parameters  must  be  identical  for  interoperability 
and  others  must  fall  within  certain  ranges.  The  database  will  also  track  some  parameters  that  do 
not  affect  interoperability. 

A  conformance  test  suite  has  been  developed,  and  a  file  transfer  functional  profile  (based 
on  FTAM)  has  been  defined.  A  new  transport  profile  is  being  developed  for  digital  circuit  switch 
connections  for  communications  supporting  the  SHAPE  and  CR  Mobile  Alternate  War  HQ.  The 
current  STAMINA  application  profile  will  be  implemented  in  the  STC  testbed. 

The  Configuration  Management  Board  (CMB)  for  STAMINA  has  agreed  [Ref.  US  1988] 
to  add  die  additional  military  features  to  the  X.400  specification,  making  it  identical  to  MMHS(84). 
Version  4.0  of  STAMINA  should  be  reviewed  for  such  compliance.  The  CMB  has  decided  to 
omit  one  part  of  STAMINA,  the  Transport  Profile  for  Analog  Circuit  Switch,  which  was  seen  as 
high  risk  and  for  which  no  interest  has  been  expressed  from  implementors.  There  are  plans  to 
develop  another  transport  profile  for  STAMINA  for  digital  circuit  switched  communications. 
NACISA  is  interested  in  studying  the  compatibility  of  STAMINA  with  the  1988  standards,  with  an 
orientation  to  migrate  toward  a  1988  base  or,  alternatively,  define  an  interface  module  between  die 
1984-  and  1988-based  systems. 

Some  STAMINA  parameters  are  left  to  be  determined  by  the  implementors  of  an  interface, 
and  some  of  these  must  be  the  same  on  both  ends  of  the  interface.  NACISA  has  developed  a 
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database  in  which  to  record  the  parameters  used  on  all  STAMINA  implementations.  NACISA  has 
begun  to  develop  a  new  project  called  the  Automatic  Message  Processing  System  (AMPS).  It 
appears  at  this  early  stage  that  it  will  have  two  aims  [Ref.  NACISA  1990]: 

*  To  provide  individual  ACE  HQs  with  automated  message  handling  capability  internal 
to  each  HQ  for  generation  of  outgoing  messages  and  to  provide  the  processing  of 
incoming  messages.  Initially,  the  messages  will  be  transmitted  via  the  existing  TARE 
system  using  TARE- unique  protocols.  Where  posable,  the  internal  processing  will  be 
based  on  X.400  oriented  systems. 

•  To  use  the  AMPS  at  each  HQ  as  the  platform  for  the  eventual  replacement  of  the  TARE 
with  an  X.400  oriented  network. 

The  interface  standards  to  be  used  with  ACE  are  expected  to  migrate  from  TARE-unique  protocols 
via  STAMINA/MMHS-84,  through  MMHS-88,  and  eventually  to  X.400  commercial  standards. 

An  ACE  ACCIS  Integrated  Testbed  is  planned  to  support  NATO  CCIS  development 
efforts,  e.g.,  the  BICES  Pilot  Study  (BPS)  effort,  with  NAOSA  serving  as  the  host  nation  and 
STC  providing  scientific  expertise  and  the  home  of  one  of  die  testbed  nodes. 

18.8  Other  NATO  Initiatives  Using  Open  Standards 

This  section  briefly  identifies  a  number  of  other  NATO  initiatives  using  or  planning  to  use 
open  standards  in  their  development  and  procurement. 

18.8.1  NATO  Initial  Data  Transfer  Service  (NIDTS)  Program 

The  NATO  Initial  Data  Transfer  Service  (NIDTS)  Program  will  establish  a  NATO  packet 
switched  network  interconnecting  NATO  organizational  subnetworks  and  selected  national 
networks.  It  will  be  used  to  link  intelligence  centers  operating  LOCE.  Phase  I  has  begun,  in 
which  NIDTS  will  acquire  the  routing  elements  and  network  management  components  to  provide 
interconnectivity  among  12  locations.  Related  to  the  NIDTS  program  is  the  cryptographic 
equipment  for  packet  switching  (CEPAS)  Program,  which  will  acquire  the  packet  encryption 
devices  for  the  NIDTS  network.  NAOSA  has  stated  that  the  NIDTS  network  will  most  likely  be 
based  on  TCP/IP  protocols.  [Ref.  Messina  1993] 

18.8.2  NATO  Internet  Architecture 

A  presentation  on  the  NATO  Internet  Architecture  was  provided  by  Mr.  Tony  Whyman 
(McCaUum  Whyman  Associates  Ltd,  UK)  to  die  October  1992  meeting  of  TSGCE  SG9/WG5. 

18.8.3  Communications  System/Network  Interoperability  (CNSI) 

CNSI  is  a  collaborative  activity  between  Canada,  France,  Germany,  the  Netherlands,  the 
United  Kingdom,  and  the  United  States,  with  participation  by  SHAPE  Technical  Centre.  The 
objective  of  the  project  is  to  demonstrate  the  technical  feasibility  of  military  communications 
systems  internetworking,  using  an  OSI-based  architecture  in  accordance  with  STANAG  4230.  It 
is  intended  that  this  demonstration  should  provide  the  background  experience  to  permit  NATO  to 
move  forward  with  the  definition  and  ratification  of  ST AN  AGs  for  interoperable  systems.  The 
project  is  governed  by  the  terms  of  the  Memorandum  of  Understanding  on  CNSI  concluded 
between  the  participating  nations  in  December  1991.  [Ref.  Bot  1993]  Project  responsibility  now 
resides  in  the  CNSI  Steering  Committee  and  its  subordinate  body,  the  Technical  Coordination 
Group  (TCG).  The  TCG  will  develop  detailed  project  plans.  Documents  of  CNSI  will  be  marked 
"in  confidence,"  and  with  distribution  limited  to  participating  nations  unless  specifically  approved 
by  the  CNSI  Steering  Committee.  [Ref.  Gee  1991] 
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The  emphasis  of  this  3-year  effort  is  not  on  developing  standards  but  rather  to  demonstrate 
the  operational  utility  of  internetworking  using  enhanced  OSI  profiles  with  military  features, 
specifically  demonstration  and  evaluation  of  multi-media  communications  extending  from  the  West 
Coast  of  the  United  States  to  the  center  of  the  European  continent  [Ref.Rigden  1991] 

The  CNSI  Project  will  provide  a  demonstration  of  die  NATO  OSI  concepts  when  applied  to 
a  variety  of  applications  supported  by  a  diversity  of  transmission  media  and  an  evaluation  of  the 
associated  protocols  and  standards  that  will  have  to  be  used  to  fulfill  the  operational  tests. 
Operational  benefits  expected  to  accrue  from  this  work  are  the  following  [Ref.  Bot  1993]: 

•  Enhanced  survivability  of  military  command,  control,  and  communications  networks, 
including  anti-jam  protection 

•  Effective  interchange  of  information  among  the  heterogeneous  C2  systems 

•  Improved  evolutionary  growth  potential  for  C2  and  communications  systems 

•  More  effective  use  of  communication  capacity. 

CNSI  will  support  both  voice  and  data  communications.  Data  communications  in  general 
will  be  packet  switched,  while  voice  communications  will  be  circuit  switched  as  a  real-time 
synchronous  bit  stream.  No  packetized  voice  will  be  used.  Voice  and  data  communications  will 
share  the  CNSI  transmission  media,  and  voice  circuits  will  be  established  on  demand.  The  set-up 
of  voice  calls  will  be  done  in  a  packet-switched  fashion  using  the  CNSI  lower  layer  protocol  stack. 
Non-voice  communications  will  be  multi-priority.  Voice  circuits  will  be  assigned  a  high  priority 
level  within  the  data  priority  scheme.  [Ref.  Bot  1993] 

The  CNSI  project  plans  a  demonstration  in  1994  for  linking  subnetworks  of  countries 
across  long  haul  multimedia  networks  supporting  multiple  modes  (voice,  data,  images).  Use  of 
HF  ground-wave  and  sky-wave,  VHF,  UHF  line  of  sight,  UHF  SATCOM,  SHF  SATCOM,  and 
land  lines  is  planned.  According  to  the  MOU  [Ref.  TSGCE  1990j],  WG3  will  (1)  ensure  that  the 
work  will  be  closely  related  to  the  recommendations,  standards,  and  draft  STANAGs  of  all  groups 
under  SG9;  (2)  provide  both  feedback  into  the  STANAG  development  process  and  practical 
experience  on  the  implementation  of  OSI  protocols  on  military  bearer  systems;  (3)  provide  reports 
on  die  demonstration  results  and  performance  to  SG9;  and  (4)  based  on  demonstration  results, 
recommend  to  SG9  the  adoption  of  promising  system  concepts  for  different  operational 
applications.  An  outline  of  the  wok  areas  originally  considered  for  the  CNSI  statementof  work  is 
given  in  Table  66. 

The  CNSI  demonstration  entails  the  creation  of  a  connectionless  internet  comprising 
multiple  subnetworks  of  different  media.  The  inter  networking  protocol  will  be  CLNP, 
(ISO  8473).  Tim  messaging  application,  based  on  X.400,  will  make  use  of  Class  4  COTS 
(ISO  8073).  The  Tactical  Data  Generator  will  use  CLTP  (ISO  8602),  enhanced  to  offer 
multicasting.  [Ref.  Bot  1993] 

Very  limited  information  on  the  progress  of  CNSI  is  generally  available,  since  CNSI  policy 
wily  allows  information  to  be  released  to  participating  nations.  This  policy  has  severely  restricted 
the  potential  liaison  with  interested  groups  in  TSGCE  SG9,  specifically  the  AHWG  on  Security 
and  WG5. 
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Table  M.  Propo— d  Work  Aims  for  CNSI 
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3MuUni(Moik  EtmBflifMnt  And  Protocols 
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a.  MuMmeda  routing 

b.  Enhanced  OSipcotocoie 

4Conmrieij|3n»  Madia  and  Sveteme 
a.  Long  haul  HF 
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e.  SATCOM  UHF 
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Pwpmm  Ttfrtw  o 


Source  Propo^Timmpf  FWfnc*  tor  W03,  Yso6e  SQ9  WQ3, 
October  1801.  NATO  UNCLASSIFIED. 


18.9  Aaalyses  Supporting  Military  Application  of  Open  Standards  and  Standards 
Deficiencies 

This  section  briefly  provides  extracts  from  analyses  conducted  by  the  nations  on  die 
potential  military  use  and  suitability  of  open  standards  and  on  deficiencies  observed  in  die  civil 
standards.  Most  of  these  extracts  are  from  die  Proceedings  of  die  Symposium  on  Military 
Communication  Networks  Interoperability  and  Standards  Held  at  die  SHAPE  Technical  Centre 
8-11  June  1993,  STC  Symposium  Proceedings  SP-10,  lone  1993.  The  analyses  are  arranged  into 
aeveral  subject  areas. 

18.9.1  NATO  Standardisation 

18.9.1.1  NATO  OSE  Reference  Model 

In  July  1993,  the  Information  Systems  Working  Group  (ISWG)  of  the  NACISC 
distributed  die  NATO  OSE  Reference  Model  (RM)  to  the  NAQSC  for  approval.  The  OSE  RM  is 
nearly  identical  to  the  POSDC  OSE  RM  (P1003.0)  [Ref.  IEEE  1992]  and  is  shown  in  Figure  24. 
Comparison  with  TRM  of  Figure  1  in  Chapter  1  shows  that  instead  of  using  a  third  dimension  to 
specify  security,  internationalisation,  ami  system  management,  the  NATO  OSE  RM  (as  well  as  the 
POSDC  OSE  RM)  identifies  these  service  areas  in  boxes  surrounding  the  operating  system 
services,  hi  addition,  the  NATO  OSE  RM  (and  POSDC  OSE  RM)  do  not  yet  address  distributed 
computing  services  as  an  eleventh  service  area.  Identification  of  the  elements  of  the  services  areas 
is  very  similar  but  not  identical  among  these  OSE  RMs. 

18.9.1.2  NATO  OSE  Baseline  Architectural  Principles 

The  NATO  OSE  baseline  architectural  principles  are  statements  of  preferred  architectural 
direction  or  practice  focused  on  how  NATO  wants  to  use  information  system  technology  in  the 
long  term.  The  objective  is  to  establish  a  context  for  standards-based  architectural  modelling  and 
help  translate  standards-related  criteria  into  a  language  that  NATO  managers  can  understand. 
These  principles,  hated  in  Table  67,  are  arranged  in  four  categories:  information  technology  policy 
matters,  life-cycle  management,  application  management,  and  technology  management  [Ref. 
NATO  OSE  1993] 
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Table  87.  NATO  08E  Basalina  Architectural  Principles 


Source:  [NATO  OSE 1993]. 


18.9.1.3  NATO  Standardization  Strategy 

A  long-term  strategy  for  standardization  activities  in  NATO  must  take  into  account  the 
following  observations  [Ref.  White  1993]: 

•  The  definition  of  requirements  for  new  systems  is  often  vague,  incomplete,  or  absent, 
so  standards  practitioners  must  make  informed  estimates  of  the  future  needs. 

•  In  a  rapidly  changing  world  where  military  involvement  can  take  many  forms — with 
mixed  forces  thinly  spread — it  is  essential  to  provide  easily  deployed  interoperable, 
user  friendly  command  and  control. 
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•  In  all  but  mobile  narrow-bandwidth  applications,  examination  of  military  features  is 
increasingly  revealing  the  adequacy  of  emergent  civil  sector  standards.  Security  and 
management  remain  focal  points  for  military  concern. 

•  In  such  circumstances,  key  distribution  for  recure  systems  becomes  a  critical 
impediment  and  indicates  the  need  for  the  use  of  asymmetric  public  key  systems,  at 
leak  for  start-up  purposes. 

•  Civil  sector  standards  are  being  driven  by  technology.  NATO  needs  to  determine 
which  areas  of  this  new  technology  it  is  likdy  to  require  for  C3L 

A  synthesis  of  there  issues  can  be  achieved  by  adopting  the  Open  Distributed  Processing 
five-view-points  model,  which  defines  a  system  from  the  viewpoints  of  enterprise,  information, 
computation,  engineering,  and  technology.  The  strategy  drawn  from  this  approach  would  focus 
on  the  following  [Ref.  White  1993]: 

•  Interactions  are  actually  needed  by  NATO  [enterprise] 

•  Application/information  is  exchanged  [information] 

•  Processing  is  required  [computational] 

•  Physical  system  will  be  needed  [engineering] 

•  Technologies  should  be  anticipated  [technology]. 

18.9.2  Coexistence  and  Convergence  of  Internet  and  OSI  Standards 

Requirements.  An  open  system  strategy  for  TCP/IP  and  other  Internet  protocols  should 
include  its  evolution  towards  ISO,  which  requires  that  the  use  of  non-OSI  compliant  applications 
(several  of  which  have  been  developed  for  TCP-IP)  be  restrained.  Some  in  presenting  the 
standards  program  do  not  admit  this  pre-OSl  offering,  but  TCP/IP  has  evolved  because  of  user 
market  forces.  There  is  no  use  in  ISO  open  system  purists  pretending  it  is  not  there-US  GOSIP 
includes  it  The  bottom  line  is  that  there  are  thousands  of  users  and  more  than  200  vendors 
offering  TCP/IP  products.  [Ref.  White  1993;  Lynch  1991] 

Convergence.113  Since  IP  only  provides  fee  minimum  functions  required  to  transport 
datagrams  from  sources  to  destinations,  TCP  provides  the  functions  to  provide  reliable  proccss-to- 
process  communications.  The  functions  provided  by  TCP  are  similar  to  those  supported  by  TP. 
Recognizing  these  similarities,  fee  National  Research  Council  recommended  in  1985  feat  the  US 
DoD  transition  toTP4.  [Ref.  Wells  1993] 

The  US  DoD,  like  other  committed  users  to  ISO  standards,  has  been  frustrated  by  a  lack  of 
available  ISO  transport-profile  products.  Therefore  it  continues  to  use  TCP/IP  wife  plans  for 
transition  to  TP4/CLNP.  Other  military  and  civil  users  are  also  plagued  by  a  lack  of  ISO  transport- 
profile  implementations.  They  are  also  turning  to  TCP/IP  products  to  solve  their  current  computer 
networking  problems. 

One  of  the  major  factors  for  fee  growth  of  TCP/IPimplementations  around  the  world,  and 
especially  in  Europe,  has  been  the  need  for  LAN/WAN  intemetworiring.  User  sites  today  are 
characterized  by  one  or  more  LANs  used  to  interconnect  PCs,  workstations,  and  servers.  LANs 
are  connected  to  a  variety  of  WAN  network  types  including  X.36,  Frame  Relay,  SMDS,  and 
point-to-point  links.  The  only  protocol  family  currently  available  to  support  fee  interconnection  of 
such  a  large  variety  of  network  types  is  TCP/IP. 


113  This  section  is  based  on  extracts  from  [WeDs  19931. 
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Recognizing  a  future  need  for  interworking  between  Frame  Relay  and  B-ISDN  networks, 
mj-TS  depicts  scenarios  where  TCP/IP  is  used  in  the  end  systems,  in  which  appropriate  relays 
ate  provided.  In  addition,  the  NATO  C3  Architecture  includes  LAN/WAN  internetworking  with 
the  use  of  TCP/IP  stacks.  The  Director  General  NACISA  has  issued  a  memorandum  [Ref. 
DGNACISA  1992]  stating  that  all  NACISA  program  managers  will  specify  the  mandatory  use  of 
TP4/C1J4P  to  ensure  interoperability  across  a  variety  of  subnetworks. 

The  development  of  “real”  ISO-based  products  for  the  LAN/WAN  internetwork 
environment  has  been  significantly  delayed  for  two  reasons:  (1)  die  connectionless  versus 
connection-oriented  debate,  and  (2)  the  ISO  process  for  developing  standards.  COTS  products  for 
LANs  and  LAN/WAN  internetworking  are  based  cm  connectionless  oriented  protocols  that  are 
either  de  facto  standards  such  as  IP  or  proprietary  protocols  such  as  Internetwork  Packet  Exchange 
(IPX).  The  TCP/IP  suite  also  includes  routing  and  management  (i.e..  Simple  Network 
Management  Protocol)  protocols.  Although  most  governments,  major  corporations,  and  NATO 
have  established  policies  for  the  use  of  KQTTU-TS  standards,  this  has  to  be  viewed  as  a  long  term 
goal.  Near-term  implementations  have  to  consider  the  availability  of  COTS  products.  For 
example,  the  European  Procurement  Handbook  for  Open  Systems  (EPHOS)  specifies  die  use  of 
ISO  standards.  However,  it  recognizes  the  real  world  need  to  consider  non-OSI  stacks  (e.g., 
TCP/IP)  for  near  term  LAWWAN  interconnections;  and  die  eventual  migration  from  this  non-OSI 
environment  to  an  OSI  one. 

NATO  should  adopt  die  same  policy  as  EPHOS  and  major  corporations  for  LAN/WAN 
environments.  It  should  no  longer  debate  die  pros  and  cons  of  connection-  and  connectionless- 
oriented  network  services,  but  should  use  proven  COTS  products  and  develop  a  migration  path  to 
an  OSI  environment  based  upon  TP4/CLNP. 

18.9.3  Architectural  Issues 

Distributed  Systems.114  A  client-server  model  provides  an  efficient  and  effective 
environment  in  which  a  user  accesses  distributed  computing  resources  and  storage  facilities 
through  user  friendly  interfaces.  A  client-server  model  basically  consists  of  workstations  such  as 
personal  computers  (PCs)  through  which  the  users  request  the  computing  services,  servers  that 
provide  the  computing  services  and  data  storage  and  a  LAN  that  transmits  data  between 
workstations,  workstations  and  servers,  and  servers.  Figure  25  shows  the  elements  of  the  client- 
server  model 


114  This  motion  is  bated  on  extracts  froa  [Ganger  19931. 
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The  functionality  provided  by  a  client-server  architecture  depends  on  the  functions  provided 
by  its  servers.  Servers  are  computing  elements  (PCs,  minicomputers,  microcomputers,  or 
mainframes)  equipped  with  the  required  software  to  provide  a  set  of  predefined  services  to  the 
users  upon  their  request  This  model  enables  distribution  of  computing  services  between  servers) 
and  workstations  and  offers  an  efficient  and  flexible  solution  in  meeting  the  needs  of  work  group 
environments.  The  client-server  model  proposed  could  involve  several  specialized  and  general 
purpose  servers  drat  may  be  called  on  to  provide  a  variety  of  services  (such  as  database  operations, 
message  handling,  image  processing,  etc.). 

To  minimize  the  number  of  the  gateways  required  in  the  NATO  C3  Architecture  and  to 
enable  die  sharing  of  computing  resources  common  to  all  or  several  Forward  Area  Systems 
(FASs),  a  backbone  system  is  proposed.  The  backbone  system  is  a  client-server  based  subsystem 
consisting  of  a  LAN,  servers  providing  services  common  to  several  or  all  FASs,  elements  to 
enable  the  data  exchange  with  other  IS  nodes,  and  workstations  to  be  used  for  system  management 
purposes.  To  differentiate  the  LAN  of  the  backbone  system  from  die  LANs  of  the  FASs  it  will  be 
referred  to  as  “backbone  LAN”  (B  LAN).  Connecting  the  LANs  of  FASs  to  the  backbone  LAN 
will  be  sufficient  to  establish  full  connectivity  within  the  IS  node  (Figures  26-28).  To  interconnect 
six  FASs,  there  will  be  a  need  for  six  gateways. 

FAS A  FAS  B 

Workstation  Workstation 


Application 


Bridge  A 


MAC 


Bridge  B 


MAC 


LAN  M  PHY  PHY  MBLANM  PHY  I  PHY  HLANBH  PHY  I  PHY 


Kay:  LLC:  Logical  Link  Control  PHY:  Physical 

MAC:  MadumAccaas  Control  BLAN:  Backbone  LAN 

Source:  [Gagnor  1903,  p.  206]. 

Figure  26.  Connection  of  Two  FASs  Through  the  Backbone  System 
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Connectionless  and  Connection-Oriented  Modes.115  The  ISO  standards 
necessary  for  subnetwork  independent  CLNS  networking  exist  but  have  not  been  validated  in  large 
scale  networks.  ISO  support  for  CONS  networking  is  subnetwork  dependent  and  limited  to  a 
single  subnetwork.  Consequently,  commercial  networking  products  available  in  the  near  future  are 
more  likely  to  support  die  CLNS  than  the  CONS.  With  the  NATO  and  member  nations’ policy  of 
COTS  procurement  wherever  possible,  the  technical  capabilities  of  the  two  modes  for  meeting  the 
military  requirements  need  to  be  determined.  This  paper  discusses  two  military  requirements 
impacted  by  the  network  service  mode,  namely  security  and  network  availability. 

The  CLNS  security  mechanisms  are  less  capable  than  those  available  with  the  CONS,  and 
high  assurance  of  end-to-end  connectionless  security  is  not  likely  to  be  available  in  the  near  future. 
While  connection-mode  network  security  is  adequate  for  all  identified  requirements,  the  adequacy 
of  connectionless  network  security  depends  on  the  class  of  application. 

Connection  mode  networks  congestion  through  allocation  of  resources  when  the 

connection  is  set  up  and  by  invoking  data  flow  control  Connectionless  networks,  which  arc  prone 
to  congestion,  discard  data  and  rely  on  users  backing  off,  which  is  inconsistent  with  the  military 
requirements  for  network  availability  and  an  acceptable  quality  of  service. 

It  is  recommended  that  NATO  support  research  into  large  scale  validation  of  the 
connectionless-mode  protocols  and  the  development  and  validation  of  subnetwork  independent 
connection-mode  protocols.  The  ability  of  the  CLNS  to  adequately  meet  the  military  requirements 
of  security  and  network  availability  under  operational  conditions  needs  to  be  determined.  Research 
in  both  network  service  modes  reduces  the  future  risk  to  NATO  in  die  provision  of  networks  to 
meet  military  requirements  under  operational  conditions. 

It  is  necessary  to  put  into  context  the  work  ongoing  in  the  ISO  community  addressing  the 
issue  of  interworking  between  the  CLNS  and  the  CONS.  ISO  TR  10172  describes  a  Transport 
Relay  Interworking  Functional  Unit,  which  enables  interworking  between  the  CONS  and  die 
CLNS  by  relaying  between  the  two  in  the  transport  layer.  Although  the  Transport  Relay  may  help 
to  achieve  interworking,  it  does  not  remove  the  need  for  communicating  end  systems  to  operate  in 
the  same  network  service  mode  if  there  is  an  end-to-end  requirement  for  functionality  provided  by 
one  mode  and  not  the  other. 

CLNP  includes  several  Subnetwork  Dependent  Convergence  Functions  (SNDCFs)  that 
provide  for  the  use  of  various  different  subnetworks,  while  die  subnetwork  independent  part  of 


115  TUt  Medan  U  baaed  on  extracts  from  [Ganger  1993]. 
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CLNP  provides  an  identical  network  service  to  the  transport  layer  regardless  of  the  actual  type  of 
subnetwork  the  system  is  attached  to.  CLNP  must  be  implemented  in  every  ES  needing  to 
interoperate  using  the  CLNS.  In  contrast  to  the  ISO  standards  support  for  the  CLNS,  no 
subnetwork  independent  protocol  has  been  developed  by  ISO  to  provide  the  OSI  CONS. 
Currently,  the  CONS  is  provided  by  the  subnetwork  dependent  protocol  specified  in  ISO  8878, 
which  maps  on  to  the  services  provided  by  X.25.  The  CONS  is  delivered  to  the  transport  layer  by 
ISO  8878,  which  can  only  run  over  a  single  X.2S  subnetwork.  An  X.25  subnetwork,  from  the 
OSI  perspective,  may  actually  be  multiple  X.25  networks  interconnected  using  X.75,  which  is  a 
non-OSI  interface  protocol  between  X.25  networks. 

No  subnetwork  independent  protocol  or  supporting  routing  procedures  have  been 
developed  for  the  CONS.  The  only  ISO  support  of  connection  mode  routing  at  present  is  limited 
to  the  application  of  ISO  10030  within  a  specific  subnetwork.  This  protocol  describes  the 
Subnetwork  Address  Resolution  Entity  (SNARE),  which  enables  an  ES  to  query  a  subnetwork- 
specific  database.  By  so  doing,  the  ES  can  determine  where  on  the  subnetwork  it  can  find  a  given 
destination.  This  protocol  is  the  most  that  can  be  currently  specified  to  support  CONS  routing  until 
a  CONS  subnetwork  independent  protocol  has  been  developed. 

In  the  connectionless  mode,  NLSP  and  TCS  are  specified  to  support  CLNP,  and  they 
provide  security  mechanisms  to  support  the  network  layer  security  services  available  with  the 
CLNS.  In  most  CLNS  networking  scenarios,  NLSP  or  TCS  will  not  be  at  the  top  of  the  network 
layer  in  order  to  provide  functionality  above  and  below  NLSP  or  TCS  to  support  segmentation  and 
re-assembly  chi  the  trusted  and  un trusted  sides  of  NLSP  or  TCS.  Consequently,  to  achieve  secure 
end-to-end  networking,  trusted  intermediate  systems,  which  perform  trusted  relaying  and  routing 
of  protected  traffic,  are  required.  These  are  difficult  to  develop  and  are  unlikely  to  be  commercially 
available  in  the  foreseeable  future. 

It  has  been  suggested  that  the  shortcomings  in  the  provision  of  CLNS  security  can  be 
overcome  through  the  use  of  transport  layer  functionality.  For  example,  security  services  may  be 
provided  by  ISO  10736,  the  Transport  Layer  Security  Protocol  (TLSP),  or  by  additional  local 
management  functionality  to  link  the  ISO  8073  Transport  Class  4  (TP4)  and  the  NLSP 
mechanisms.  Both  methods  rely  on  the  functions  of  the  TP4  mechanisms  for  their  operation. 
Therefore,  if  rigorous  military  security  is  to  be  applied  to  the  connectionless  mode,  TP4 
implementations  must  be  bruit  to  the  required  assurance  levels  in  addition  to  NLSP  or  TLSP. 
Delivery  of  highly  assured  TP4  mechanisms  is  believed  to  be  beyond  the  current  and  foreseeable 
security  evaluation  techniques  for  high  assurance. 

Much  work  has  been  performed  by  the  military  community  on  network  layer  security  for 
both  connection-  and  connectionless-mode  networks.  Within  the  constraints  of  the  modes, 
excellent  technical  solutions  have  been  developed.  This  work  has  influenced  the  development  of 
NLSP  through  the  national  standards  bodies.  The  end-to-end  provision  of  the  CONS  has  been 
assumed  in  die  development  of  security  protocols  to  provide  security  services  to  meet  the  NATO 
requirements.  The  connectionless  mode  security  services  are  always  less  capable  than  the 
connection-mode  security  services,  particularly  for  the  provision  of  integrity.  Security  in  the 
connection-mode  environment  is  adequately  provided  by  NLSP  with  the  TCS  enhancements,  but 
in  the  connectionless  environment  the  available  security  services  may  not  be  adequate  for  some 
classes  of  application.  Since  the  security  services  required  must  be  defined  in  accordance  with  the 
total  system  security  requirement,  for  many  applications  sufficiently  secure  communications  may 
be  achieved  using  either  mode. 
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Connection  Orientation.11*  Table  68  summaries  the  chief  features  of  CLNS  and 

CONS. 

The  end-to-end  provision  of  die  CONS  has  been  assumed  in  die  development  of  the  NATO 
TCS,  which,  through  the  NATO  member  nations,  has  influenced  the  development  of  ISO  NLSP. 
The  connectionless  security  services  are  less  capable  than  the  connection-mode  security  services, 
particularly  for  the  provision  of  integrity,  so  the  connectionless  mode  may  be  inadequate  for  some 
classes  of  application. 


Table  <8.  Salient  Features  of  the  CLNS  and  CONS 


CLNS 

CONS 

Interoperability 

Not  Interoperable  with  CONS 

Not  interoperable  with  CLNS 

Networking  Standards 

Ful  eat  exieU;  neede  validation 

Need  further  development  end 
validation 

Security  Servicee 

Adequacy  depends  on  requirement; 
Trusted  ISe  required  for  end-to-end 
security 

Adequate  for  ail  known  requirements; 
Trusted  ISs  not  required  for  end-to- 
end  security 

Route  Alocation 

On  each  packet  and  to  end 

At  connection  set-up  and  localized  re¬ 
routing  after  route  falure 

Error  Recovery 

End  to  end  recovery  traffic 

Localized  recovery  traffic 

Packet  Overheads 

Kfigher 

Lower 

Packet  Size 

Unpredictable  eegmentetion  withir? 
network,  reducing  performance  end 
promoting  congestion 

At  connection  set-up  size  negotiated 
down  to  maximum  that  can  be 
deiiverad  by  ell  subnetworks 

Congestion  Control 

Catastrophic  congestion  poeeble, 
even  in  benign  environment:  decerds 
data,  reiiee  on  user's  backing  off 

Prsdtetabiy  controlled  through 
mourCfl  Mocauon  ana  now  control 

Source:  (Turner  1903). 


For  end-to-end  security  in  die  connectionless  mode,  trusted  ISs  are  required;  these  are  not 
likely  to  be  available  in  the  foreseeable  future.  Trusted  ISs  are  not  required  for  end-to-end-security 
in  the  connection  mode.  Highly  assured  transport  layer  security  functionality  to  supplement  CLNS 
network  layer  security  functionality  is  not  likely  to  be  available  for  the  foreseeable  future. 

Connectionless  networks  are  more  vulnerable  to  congestion  than  connection-mode 
networks  because  in  connectionless  networks,  management  actions  such  as  error  recovery  and  re¬ 
routing  are  end-to-end  actions  leading  to  greater  traffic  for  all  subnetworks.  In  connection-mode 
networks,  error  recovery  and  re-routing  mechanisms  are  localized. 

Packet  overheads  are  higher  in  connectionless  networks  than  connection-mode 
subnetworks.  Spontaneous  segmentation  in  connectionless  networks  gives  rise  to  unpredictable 
traffic  generation  and  degradation  of  performance  due  to  increased  switching  overheads  and 
increased  probability  of  congestion.  In  connection-mode  networks,  the  packet  size  is  negotiated 
down  at  connection  set-up  to  the  maximum  size  that  can  be  delivered  by  the  traversed 
subnetworks. 

Relief  of  congestion  in  connectionless  networks  relies  on  discarding  data  and  network 
user’s  backing  off,  which  is  inconsistent  with  the  military  requirements  of  network  availability  and 
acceptable  quality  of  service.  Catastrophic  congestion  is  a  known  problem  of  connectionless 


116  This  section  ii  based  oo  excerpts  from  (Turner  1993]. 
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networks,  typically  doe  to  retransmissions  of  discarded  packets.  Connection-mode  networks 
manage  congestion  through  resource  assignment  when  the  connection  is  set  up,  with  data  flow 
control  invoked  as  necessary  to  provide  reliable  end-to-end  data  transfer. 

Multicasting.  Table  69  summarizes  multicasting  requirements. 


Table  69.  Summary  of  Multicasting  Services  Required  by  Application 


Service*/ 

Application 

Group  Opan/Closad, 
Determinate/ 
Indeterminate, 
Static/Dynamic, 

Six* 

Communication 

1  -way/2-sray  / 
n-way, 

Fixad/Singla/ 

Unrestricted 

Transmission 

Reliable/ 

Unreliable, 

Synchronised/ 

Unsynchronized 

Data  Rate, 

Throughput, 

Delay 

Distributed 

Simulation 

Closed,  Determinate, 
Dynamic,  100-10,000 

msmbsrs 

n-way,  unrestricted 

unreliable  or  reiiabis; 
Unsynch 

High  rates. 
Realtime  or 
near  real  time 

Tactical 

Messaging 

Closed,  Determinate, 
Dynamic,  2-10  msmbsrs 

n-way,  unrestricted 

ratable.  Unsynch. 

some  reel  time 
constraints 

Print;  TO 

Updates 

Dstsrminats,  Static,  75- 
200mambsrt 

2-way,  single 
transmitter 

ratable,  Synch. 

non-raakime 

knag*  Distribution 

Cloaed,  Dsterminste, 
Dynamic,  2-100  msmbsrs 

2-way,  single 
transmitter 

ratable.  Unsynch. 

knag*  she  up 
to  100  Mb. 

Naval  platforms 

Dosed,  Determinate, 
Static.  20  members 

1-way,  single 
transmitter 

ratable  or  unreliable: 
Unsynch. 

near  reel  time 
or  real-time. 

Computer- 
Support  ad 
Cooperative  Work 

Doead,  Dstsrminats, 
Dynamic,  3-200  msmbsrs 

2-way,  single 
transmitter 

ratable  (text), 
unreliable  (video). 
Unsynch. 

near-real  tims 

Source:  [Tumor  1993]. 


18.9.4  OSI  Issues 

Quality  of  Service.  Early  work  in  QoS  tended  to  focus  on  a  set  of  general  qualities  of 
service,  using  functional  groupings  such  as  quality  of  addressing,  quality  of  message  (Le., 
integrity),  quality  of  timeliness,  quality  of  confidentiality,  and  quality  of  cost,  although  later  work 
in  NATO  suggested  that  interoperability,  quantity,  frequency,  services,  security,  “quality,” 
timeliness,  availability,  and  survivability  were  die  specific  qualities  of  interest  to  die  military.  [Ret 
Sluman  1993] 

Military  Messaging:  ACP-127  and  A  CP-123.  Apart  from  standards  for  common 
application  service  elements  (CASE)  provided  by  ISO,  and  the  range  of  civil  applications  with 
obvious  military  use  (FAX,  voice,  video,  etc.),  messaging  is  an  established  military  application, 
although  it  has  been  evolved  in  a  fairly  ad  hoc  way  over  many  years.  The  NATO  messaging 
standard  ACP-127  is  used  by  over  70  nations.  ACP-123  is  a  future  messaging  standard  being 
developed  by  Australia,  New  Zealand,  Canada,  the  United  Kingdom,  and  the  United  States  ACP- 
123  is  intended  to  be  a  complete  stand-alone  definition,  including  protocols,  for  message 
exchange.  These  standards  are  also  being  developed  to  cater  use  over  limited  capability  HF 
channels  and  over  a  busy  packet  switched  network.  The  messaging  element  is  based  on  X.400, 
but  is  not  formally  aligned  with  the  SG9  program,  which  contains  a  series  of  X.400  bases  MMHS 
standards  and  includes  provision  for  ACP-127.  [Ref.  White  1993] 

Analyses,  Simulations,  and  Demonstrations  for  Use  of  X.400.117  An 
analysis  was  conducted  in  1991  of  a  typical  X.400  message  converted  from  an  ACP-127  message 

117  This  tectkxi  it  bated  on  excerpts  from  [Bryant  1993], 

Chapter  18  425  NATO  Initiatives 

UNCLASSIFIED 


UNCLASSIFIED 


to  examine  header  overhead.  For  a  seven-recipient  message,  over  3  kbytes  of  overhead  were 
required  to  generate  die  X.400  envelope  and  header,  whereas  an  equivalent  ACP-127  message  has 
an  overhead  of  O.S  kbytes.  Substantial  contributors  to  the  X.400  overhead  were 
originatoo'recipient  addresses,  trace  information,  security  features,  and  encoding  techniques.  [Ref. 
McArthur  1991] 

A  traffic  simulation  was  conducted  in  1992  by  MITRE  for  DISA.  The  recommendation 
from  that  study  was  that  a  full  OSI  stack  can  be  deployed  in  those  tactical  systems  having  more 
bandwidth  and  processing  capable  systems  [such  as  the  Mobile  Subscriber  Equipment  (MSE)],  but 
that  in  general  OSI  is  not  recommended  for  use  in  tactical  radio  systems  that  must  support  near- 
real-time  delivery  requirements.  [Ref.  MITRE  1993] 

Participating  in  the  third  Strategic-Tactical  Data  Network  (STDN-3)  demonstration,  DISA 
evaluated  X.400  for  strategic-tactical  interoperability  and  concluded  that  X.400  electronic  mail  can 
support  that  interoperability.  X.400  appeared  suitable  from  a  performance  aspect  for  relatively 
high-bandwidth  tactical  networks  such  as  the  US  Army  Tactical  Packet  Network  (TPN),  which 
includes  MSE.  There  was  no  substantial  difference  in  performance  between  X.400  and  its  current 
alternative,  SMTP.  No  conclusions  were  reached  for  radio  links.  An  overall  result  was  a  basis  for 
optimism  for  military  message’s  being  able  to  extend  from  the  strategic  community  well  into  the 
tactical  community  without  die  drawbacks  of  specialized  gateways. 

Evaluation  of  ASN.l  Enhancements  for  Tactical  Data  Communications.118 
A  significant  portion  of  any  ASN.l  encoded  PDU  is  occupied  by  overhead  bits  such  as  tag  values, 
length  octets,  and  pad  bits.  For  small  message  sizes  (i.e.,  fewer  than  10,340  octets),  such  as  those 
used  for  tactical  C3,  the  amount  of  overhead  is  at  least  1 1  percent  For  5,120-octet  messages,  the 
overhead  figure  is  approximately  30  percent  and  for  a  2,048-octet  message  (not  uncommon  for 
tactical  applications)  the  encoding  overhead  exceeds  60  percent  Note  that  encoding  overhead  is 
exceeded  by  X.400  overhead,  which  adds  typically  200-300  percent  overhead  to  user-supplied 
message  bodies  fewer  than  10,240  octets  in  size  [Ref.  Bonatti  1993]. 

Several  techniques  can  be  used  to  minimize  encoding  overhead,  including  tag  and  length 
octet  omission,  intelligent  ordering  of  fields  in  the  abstract  syntax,  nesting  omission,  numeric 
range  adjusting,  and  bit  alignment  These  are  addressed  by  the  following  proposals,  now  being 
incorporated  into  encoding  standards  [Ref.  Bonatti  1993]: 

•  Packed  encoding  rules  (PER).  PER  (DIS  8825-2.2)  provides  a  more  compact  form  of 
tag-length-value  encoding  that  is  faster  to  process  than  the  BER.  PER  uses  octet- 
aligned  tag-length-value  encoding  in  which  the  type  and  length  identifiers  are 
frequently  omitted.  It  also  uses  tag  omission,  length-code  omission,  and  numeric 
range  adjustment  techniques  to  minimize  encoding  overhead. 

•  Distinguished  encoding  rules  (DER).  DER  (DIS  8825-3)  uses  a  tag-length-value 
format  similar  to  BER  but  eliminates  the  many  alternative  encodings  that  are  possible 
with  BER.  The  DER  is  useful  in  cases,  such  as  cryptography,  where  independently 
generated  encodings  must  be  identical. 

•  Lightweight  encoding  rules  (LWER).  LWER  (DIS  8825-2.2/WDAM1)  does  not  use 
tag-length-value  encoding  but  an  alternative  that  is  faster  to  process  because  the 
encodings  generated  are  similar  to  commonly  used  local  storage  formats.  LWER  is 
designed  to  maximize  processing  speed  of  the  encoder  at  the  expense  of  flexibility, 
extensibility,  and  compactness.  It  does  so  by  defining  the  transfer  syntax  to  match  the 

US  This  teetkn  is  baaed  on  excerpts  from  [Booatti  19931. 
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local  representation  format  as  closely  as  possible  through  the  use  of  six  new  transfer 
syntaxes  that  cover  a  broad  spectrum  of  representation  formats.  These  syntaxes  define 
rales  with  varying  word  sizes  and  octet  ordering  schemes.  Since  LWER  will  generally 
increase  encoding  overhead  significantly,  it  is  primarily  useful  in  high-speed 
applications  where  bandwidth  is  plentiful  or  where  processing  resources  are  extremely 
limited.  The  latter  case  might  apply  to  some  tactical  scenarios,  such  as  hand-held- 
device  satellite  communication  (SATCOM). 

•  Minimum  basic  encoding  rales  (MBER).  MBER  [Ref.  Blum  1990]  was  proposed  by 
the  civil  aeronautical  community,  whose  aim  is  similar  to  PER,  but  with  a  more 
aggressive  approach.  A  unique  aspect  of  MBER  is  employment  of  bit  alignment  to 
further  reduce  the  size  of  resulting  encodings.  This  feature  requires  a  new  ALIGN 
constraint  for  the  ASN.l  notation,  which  would  allow  abstract  syntax  developers  to 
specify  particular  alignment  requirements  (e.g.,  octet  alignment)  for  any  field.  Many 
of  the  MBER  features  have  been  used  in  PER,  but,  because  MBER  offers  significantly 
lower  encoding  overhead  than  PER,  its  proposals  may  need  formal  consideration. 
MBER  has  not  yet  been  submitted  to  ISO  as  a  separate  standard. 

OSI  Management.  SG9  has  concluded  that  there  are  no  special  features  required  for 
military  managed  objects  within  the  ISO  managed  objects  model  of  management  Indeed,  SG9  has 
yet  to  definitively  establish  any  uniquely  military  object  The  main  area  of  concern  is  whether 
management  is  sufficiently  secure.  Security  features  available  to  all  applications  may  suffice, 
provided  there  is  an  understanding  of  the  QoS  and  security  parameters  for  management  [Ref. 
White  1993] 

Network  Management119  Network  management  standards  are  targeted  at  the  data 
communications  area.  In  the  telecommunications  area  there  are  additional  requirements  that  can  be 
met  by  a  supplementary  set  of  standards.  These  are  collectively  known  as  Telecommunication 
Management  Network  (TMN)  and  are  described  in  a  number  of  ITU-TS  recommendations 
(M.3xxx  series).  Furthermore,  there  are  ISDN-related  recommendations  for  testing  at  the  network 
interface  level  (Q.94x  series).  It  is  expected  that  the  NOSIP  Strategy  over  time  will  be  expanded  to 
encompass  all  relevant  communication  profiles  by  including  the  standards  that  are  relevant  for 
telecommunications  management  [Ref.  Christiansen  1993] 

Within  the  NATO  community  there  are  existing  systems  and  equipment  that  will  be 
prohibitively  expensive  to  adapt  to  international  standards.  Among  these  are  switching  systems 
(i.e.,  IVSN),  backbone  systems  (i.e.  SATCOM  and  NTTS)  and  special  equipment  (e.g., 
cryptographic  units).  These  systems  implement  their  own  proprietary  protocols  and  services. 
They  cannot  be  discarded  in  the  near-term  future  and  they  will  have  to  be  an  integrated  part  of  the 
future  system.  The  challenge  is  to  decide  how  much  to  invest  in  accessing  them  from  a 
management  point  of  view.  Some  standards  do  anticipate  non-standard  systems  by  allowing  for 
proxies  (within  OSI)  or  mediation  devices  (within  TMN).  These  implement  a  standards-compli ant- 
object  as  front-end  for  the  non-compliant  element.  The  number  of  these  front-ends  is  expected  to 
decrease  over  time.  This  is  expected  to  happen  when  the  non-standard  devices  are  replaced  by 
standard  compliant  resources. 


119  This  lection  it  based  oo  excerpts  from  [Christiansen  1993]. 
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18.9.5  ISDN  Issues 

Use  of  ISDNs.12*  After  a  period  of  field  trails  in  the  late  1980s,  public  ISDN  services 
became  commercially  available  in  most  West-European  countries  between  1989  and  1992.  In  Eire, 
Greece,  and  Turkey,  public  ISDN  will  start  in  1993.  Currently,  most  European  countries  offer 
public  ISDN  services  in  the  major  cities  using  a  national  version  for  user-network  signaling. 
However,  all  the  major  European  public  telecommunication  service  providers  agreed  on  a 
memorandum  of  understanding  (MOU)  about  providing  ISDN  access  and  ISDN  services  in  a 
harmonized  way.  The  MOU  will  be  implemented  in  three  steps.  Step  1  ensures  that  ISDN  will  be 
available  in  all  European  countries  in  a  basic  harmonized  version  by  the  end  of  1993.  Although  the 
services  of  Step  1  are  very  limited,  it  will  provide  a  European-wide  standardized  user-network 
protocol  that  is  the  precondition  for  terminal  portability  within  Europe.  In  Step  2  some  bearer  and 
supplementary  services  will  be  added  by  the  end  of  1994.  The  most  important  services  of  Step  2 
are  probably  the  packet  switched  services  within  the  B-  and  D -channels.  After  completion  of 
Step  3  the  whole  set  of  agreed  services  will  be  available.  There  is  no  fixed  schedule  for  Step  3, 
but  it  is  expected  to  be  implemented  by  the  end  of  1995. 

The  situation  in  North  America  is  more  difficult  than  in  Europe  because  of  independent 
local  telecommunication  service  providers.  After  a  period  of  non-compatible  ISDN  islands 
“ISDN  1”  was  developed  as  a  nationwide  ISDN  service  providing  standardized  Basic  Access. 
The  interfaces  and  protocols  are  implemented  according  to  standards  from  ANSI  and  NIST. 
Unfortunately,  the  North  American  ISDN  standards  are  slightly  different  from  the  European  ISDN 
standards.  ISDN  1  was  presented  nationwide  at  the  end  of  1992  in  the  “Transatlantic  ISDN 
Project  The  next  step  will  be  “ISDN  2,”  which  will  also  support  Primary  Rate  Accesses. 

If  the  basic  infrastructure  is  in  place,  ISDN  can  be  used  for  a  variety  of  services  and 
applications  such  as: 

(a)  Interconnecting  LANs  through  routers  at  much  higher  data  rates  than  are  available  via 
analog  telephone  networks. 

(b)  Providing  ISDN  teleservices  (e.g.,  telephony,  video,  high-speed  facsimile). 
Teleservices  can  be  provided  stand  alone  or  in  integrated  packages  that  will  facilitate 
the  development  of  multimedia  applications.  In  the  user  area,  teleservices  can  also  be 
integrated  with  OSI  applications  such  as  FT  AM  or  message  handling. 

(c)  Relatively  high-speed  bearer  capability  for  access  to  packet  switched  networks. 

Bearer  and  teleservices  can  be  augmented  by  a  variety  of  supplementary  services,  such  as 

voice  and  video  conferences,  calling  line  identification,  closed  user  groups,  etc.,  provided  by  the 
public  ISDNs  or  by  the  end-systems.  Multilevel  precedence  and  preemption  has  been  standardized 
by  1TU-TS.  Nevertheless,  it  is  still  open  whether  and  when  it  will  become  available  as  a  publicly 
available  supplementary  service. 

The  AHWG  on  ISDN  in  TSGCE  SG9  provides  guidance  and  standards,  based  on  civil 
standards  developed  by  ITU-TS,  ETSI,  and  ANSI,  in  the  following  areas  [Ref.  Stollenmayer 
1993]: 

•  ISDN  user-network  interfaces  and  protocols 

•  ISDN  inter-exchange  signalling  systems  such  as  CCS7  and  QSIG 

•  ISDN  services  such  as  bearer  services,  teleservices  and  supplementary  services 


120  This  section  is  based  on  excerpts  from  [StoUeameyer  1993]. 
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•  ISDN  security  (in  liaison  with  the  SG/9  ad  hoc  group  on  security) 

•  ISDN  and  OSI  related  issues 

•  ISDN  numbering  and  addressing. 

Use  of  OSI  and  ISDN  in  SATCOM.121  It  has  been  successfully  demonstrated  that 
SATCOM  links  supporting  static  and  mobile  users  can  be  integrated  into  networks  utilizing  OSI 
and  ISDN  standards.  The  SATCOM  link  provided  a  bit  stream  service  (64-2048  kbit/s)  without 
any  special  protocol  enhancements.  The  choice  of  protocol,  protocol  options,  and  variables  is 
critical  in  achieving  good  performance  with  SATCOM  links.  An  example  scenario  for  use  of  OSI 
and  ISDN  in  SATCOM  is  provided  in  Figure  29. 


Bid  Spam  Ini— dhu  In— mndWi  EndSp—n 


Figure  29.  OSI  End-to-End  Configuration  with  Connectionless  Network  Protocol 

In  order  to  achieve  the  tests  performed  to  date,  several  test  beds  were  developed  and 
interconnected  at  STC.  As  a  result,  the  value  of  using  rapid  prototyping  and  integrated  test  beds  to 
achieve  quick  results  was  demonstrated. 

A  critical  aspect  of  achieving  good  throughput  is  the  error  recovery  technique  that  must  be 
compatible  with  the  SATCOM  delay  and  error  characteristics;  the  OSI  transport  protocol  Class  4, 
as  implemented  in  the  STC  OSI  test  bed,  was  found  to  give  good  performance  and  is  also  tolerant 
to  slips.  In  the  case  of  low  capacity  noisy  links,  further  study  is  required  in  order  to  identify 
optimum  protocols,  particularly  where  signal  processing  functions — such  as  spread  spectrum  and 
coding — introduce  additional  delay. 

For  data  applications,  the  typical  error  performance  of  SATCOM  links  (10*$  for  >99.9)  is 
adequate  to  support  OSI/ISDN  services,  assuming  the  use  of  TP4  for  data  applications; 
furthermore,  two  links  in  tandem  could  be  utilized  while  achieving  an  acceptable  throughput  The 
use  of  concatenated  forward  error  coding  (inner  convolutional/Viterbi,  outer  Reed-Solomon) 
enables  error  performance  of  10*10  to  be  achieved  with  a  modest  bandwidth  expansion. 


121  ThU  tectioo  is  based  on  excerpts  Cram  [Hind  1993], 
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18.9.6  Multimedia  and  Packet  Radio  Technology 

Multimedia.  XTV  (X  Teleconferencing  and  Viewing),  a  workstation-based  collaborative 
computing  system  in  the  X-Window  environment  that  allows  geographically  separated  users  to 
simultaneously  view  and  manipulate  shared  images,  documents,  or  programs  while  they 
communicate  via  audio  and  possibly  video  links.  XTV  is  a  public  domain  system  developed  by 
Old  Dominion  University  and  the  University  of  North  Carolina  at  Chapel  Hill.  XTV  allows  a 
conference  to  be  created  around  one  or  more  arbitrary  X  applications.  Participants  have  the  same 
view  of  shared  applications  and,  by  following  a  simple  floor  passing  protocol,  may  control  the 
shared  applications.  As  an  X-based  application,  it  can  operate  in  any  X-based  environment,  on  a 
TCP/IP  network.  XTV  offers  almost  unlimited  flexibility  within  an  X-based  environment  because 
it  is  designed  to  facilitate  the  sharing  of  any  X-based  application.  [Ref.  Turner  1993] 

In  the  usual  model  of  X,  the  user’s  workstation  (the  server)  interacts  over  a  network  with 
tiie  application  (the  client),  hi  XTV,  the  server  acts  as  a  conference  master  and  shares  the  output 
from  the  application  with  other  conference  participants.  A  token  determines  which  conference 
participant  is  controlling  input  to  the  application  at  any  time.  At  present,  XTV  uses  multiple  TCP 
transmissions  for  the  output  from  the  conference  master  to  the  conference  participants.  The 
multiple  TCP  transmissions  used  previously  for  the  output  from  the  server  conference  chair  to  the 
many  conference  participants  have  been  replaced  by  TP4  with  extensions  providing  a  reliable 
one-to-n  multicast  service  with  two-way  data  flow.  [Ref.  Turner  1993] 

Packet  Radio  Architecture.  The  architecture  of  packet  radio  networks  can  be 
classified  as  centralized  or  distributed.  In  a  centralized  network,  there  is  one  central 
transmitter/receiver,  attached  to  a  central  resource.  All  other  nodes  communicate  only  with  the 
central  node.  Node-to-node  communication  is  indirect,  mediated  by  the  central  node.  The  earliest 
networks  followed  tins  model,  and  were  designed  primarily  to  provide  terminal  access  to  a  central 
time-sharing  system.  In  a  centralized  system,  two  radio  channels  are  required.  Individual  nodes 
send  packets  to  the  central  node  on  one  channel,  and  the  central  node  broadcasts  packets  on 
another.  Since  radio  transmission  is  omnidirectional,  packets  transmitted  by  the  central  node  are 
heard  by  all  the  other  nodes.  Thus  the  configuration  is  logically  equivalent  to  a  multipoint  line  with 
a  primary  and  a  number  of  secondaries.  [Ref.  Stallings  1991] 

The  first  packet  radio  network,  ALOHANET,  was  developed  by  the  University  of  Hawaii 
and  became  operational  in  1970.  Its  principal  objective  was  to  allow  user  terminals  in  widely 
scattered  locations  to  access  the  university  computer  system.  Traffic  was  primarily  terminal-to- 
host,  but  terminal-to- terminal  traffic  could  be  routed  via  the  central  node,  called  the  menehue 
(Hawaiian  for  “imp”).  Remote  units  were  of  two  types.  The  terminal  control  unit  (TCU)  operated 
with  a  simple  half-duplex  terminal  and  included  a  buffer,  control  logic,  and  transceiver.  The 
programmable  control  unit  (PCU)  was  a  microprocessor-based  device  for  terminal  concentration 
and/or  a  computing  station. 

An  increasingly  common  application’of  distributed  packet  radio  is  to  provide  distributed 
networking  among  personal  computers,  including  access  to  centralized  computing  resources.  In 
most  cases  these  networks  consist  of  amateur  radio  stations  and  are  open  to  any  user  who 
conforms  to  the  protocol  used  on  a  particular  network. 

Amateur  packet  radio  networks  exist  in  a  number  of  areas  throughout  North  America,  and 
the  number  is  growing  steadily.  An  effort  to  standardize  these  networks  has  been  underway  since 
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1982,  under  the  sponsorship  of  the  American  Radio  Relay  League  (ARRL),  which  has  produced  a 
standard  for  a  link-level  protocol  suitable  for  packet-radio  networks  known  as  AX.25. 

An  ARRL-type  network  is  a  distributed  network,  organized  into  clusters  of  stations 
connected  by  repeaters.  All  stations  and  repeaters  share  a  single  frequency  for  transmission  and 
reception.  The  AX.25  standard  does  not  specify  the  frequency  to  be  used.  Based  on  FCC- 
approved  channel  availability,  the  typical  network  uses  the  220- MHz  band,  using  FSK  and  with 
ALOHANET,  a  fixed  routing  scheme  is  used.  In  this  case,  the  route  to  be  followed  is  specified  by 
the  source  station,  as  explained  below,  (p.336) 

The  most  important  difference  between  AX.25  and  HDLC  is  in  the  addressing  technique. 
In  HDLC,  there  are  two  possible  configurations:  A  point-to-point  link  with  two  stations,  and  a 
multidrop  link  with  one  primary  and  multiple  secondaries.  In  either  case,  a  single  address  is 
sufficient  for  the  operation  of  the  protocol 

18.9.7  Software  Standards  for  NATO 

Software  Standards  Study.  A  Software  Standards  Study  was  completed  in  March 
1992  by  the  Information  Systems  Working  Group  (ISWG)  of  the  NACISC.122  This  document 
provides  substantive  recommendations  regarding  the  potential  viability  of  adoption  by  NATO  of 
standards  in  specific  areas  of  software-based  systems.  It  addresses  international  standardization 
efforts  in  the  areas  of  operating  systems,  user  interfaces,  interoperability  and  networking,  and 
database  languages,  which  are  believed  by  the  ISWG  to  be  the  most  beneficial  to  NATO  in 
adopting  an  open  systems  approach.  The  survey  of  standards  contained  in  the  annexes  of  the 
Software  Standards  Study  provides  major  supplementary  material  to  the  top-level  information 
provided  in  this  document  This  is  particularly  true  of  the  information  the  Software  Standards 
Study  provides  on  UNIX  standardization  (Annex  A,  180  pages),  graphical  user  interfaces 
(Annex  B123,  26  pages),  and  database  query  language  (Annex  C,  20  pages).  The  architecture 
framework  for  the  Software  Standards  Study  is  shown  in  Figure  30. 

As  seen  from  the  list  of  technical  annexes  given  above,  the  Software  Standards  Study 
focuses  on  only  three  areas  of  the  architectural  framework  shown  above:  UNIX  and  POSDC  for 
the  Platform  Area;  graphical  user  interfaces  for  die  User  Area;  and  database  query  languages  for  the 
Language  Area.  Interoperability,  as  defined  in  die  study,  is  the  ability  of  applications  running  on 
software  and  hardware  from  multiple  vendors  to  communicate  meaningfully.  Interoperability  and 
networking  are  treated  in  the  study  only  in  relation  to  UNIX  data  formats  and  communications 
protocols  (currently  dominated  by  use  of  TCP/IP  in  the  UNIX  market).  A  migration  towards  OSI 
is  seen  as  gaining  momentum. 

The  following  are  issues  about  the  characterization  of  standards  needed  and  available  to 
support  die  architectural  framework  (Figure  30): 

•  The  study  overestimates  the  need  and  value  of  adopting  a  common  operating  system 
for  NATO  and  poorly  characterizes  UNIX,  which  is  recommended.  Indeed,  UNIX  is 
cited124  as  “a  typical  example  of  an  open  system.”  Incompatibility  problems  among 


122  Software  Standards  Study,  AC/31 7(W/2)N/3 32,  Final  Draft,  NATO  Communications  id  Information 
Systems  Committee,  Information  Systems  Working  Group,  26  March  1992,  NATO  UNCLASSIFIED. 

123  Annex  B  is  based  on  a  study  conducted  for  the  Canadian  Department  of  National  Defence  by  APG,  lnc„ 
30  September  1991  (Prefect  GUI01.9102). 

124  Software  Standards  Study,  op.  dt.  Section  4.1  (p.  4). 
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various  versions  of  UNIX  from  different  vendors  is  noted.  POSIX  is  claimed123  to 
be  a  series  of  operating  system  standards  that  “could  provide  the  ultimate  goal  of  both 
source  level  and  possibly  object  level  compatibility.” 

•  The  study  asserts126  that  “SUN's  Network  File  System  (NFS)  for  distributed  file 
systems  is  a  guarantee  for  file  system  interoperability”  and  “POSIX  standardization  of 
die  tape  archive  utility  assures  interoperability  of  data  formats  among  UNIX  users” — 
such  assertions  seem  far  from  the  truth,  given  the  other  requirements  in  data 
management  and  data  standardization,  not  to  mention  other  aspects  of  transfer 
mechanisms  and  data  presentation  syntax  that  are  required  for  interoperability. 

•  The  need  and  role  of  application  program  interfaces  (APIs)  for  portability  (and 
interoperability)  are  not  addressed. 

•  Security  is  only  addressed  by  noting  the  growing  availability  of  secure  UNIX 
operating  systems  and  certified  UNIX  products,  with  the  note  that  computer  security 
evaluation  may  be  required  to  determine  whether  the  integration  process  has  created 
vulnerabilities  not  identified  in  the  individual  product  evaluation. 

•  OSF/Motif  was  selected  based  on  an  analysis  of  26  criteria;  however.  Motif  and  OPEN 
LOOK  had  neatly  identical  (within  3  percent)  raw  and  weighted  scores,  and  no  clear 
rationale  for  choosing  Motif  over  OPEN  LOOK  was  given.  Windows  3.0  was 
recommended  for  MS  DOS  platforms. 


Figure  30.  Architecture  Framework  for  Software  Standards  Study 

Among  the  recommendations  made  in  the  study  are  the  following: 

•  NATO  establish  adoption  criteria  and  procedures  to  allow  implementation  of  Open 
System  Architectures  and  internationally  agreed  standards. 

•  NATO  adopt  UNIX  as  the  standard  operating  system  platform  for  all  communications 
and  information  system  and  management  information  system  applications. 

•  NATO  require  that  all  its  UNIX  platforms  and  products  are  in  conformance  with  the 
X/OPEN  Portability  Guidelines.  This  includes  for  the  basic  UNIX  environment 
adherence  to  the  following  standards: 

-  POSIX.  1 

-  Draft  POSIX.2 


123  Ibid. 

1 26  Software  Standards  Study,  op.  dt.  Section  4.1.2  (pp.  5-6). 
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ANSI-X3.159-1989  C-l  anguage  standard  (only  in  the  exceptional  circumstances 
where  conformance  to  the  NATO  Ada  policy  is  not  possible  and  a  waiver  is 
granted) 

X- Window  System 

ANSI  SQL  standard  with  X/OPEN-defined  system  dependencies. 

•  NATO  closely  monitor  the  evolving  UNIX  standardization  process  to  ensure  rapid 
access  to  the  new  developments. 

•  NATO  adopt  MOTIF  as  the  standard  graphical  user  interface. 

NATO  Software  Standards.  In  March  1993,  the  NACISC  noted  die  recommendations 
of  the  Software  Standards  Study  cited  above.  Without  endorsing  the  recommendations,  die 
NACISC  provided  wide  circulation  of  the  results  within  NATO  and  die  nations.  [Ref. 
NACISC  1993e] 

Software  Methods  and  Tools  Study.  In  July  1993,  the  Ada  Implementation 
Subgroup  (AISG)  of  dm  ISWG  distributed  three  papers  addressing  software  methods  and 
integration,  integration  guidance,  and  development  tools.  This  effort  was  an  outgrowth  of  a 
project  on  life  cycle  methodology  conducted  during  the  period  1988-1991.  The  project  reviewed 
die  major  software  development  and  maintenance  methods  in  general  use,  together  with  their 
associate  automated  tool  support,  for  three  classes  of  systems:  automated  management  information 
systems,  real-time  embedded  systems,  and  C31  systems.  The  1993  recommendations  are  the 
following  [Ref.  NACISC  1993d]: 

•  The  methods  identified  in  the  study  as  currently  commercially  viable  can  now  be  used 
effectively  by  NATO. 

•  In  order  to  provide  full  systems  life  cycle  support  within  NATO,  it  is  necessary  to 
assess  the  integration  of  the  identified  methods  into  a  life  cycle  methodology. 

•  Adequate  data  now  exists  in  order  to  assess  and  identify  suitable  existing  full  life  cycle 
methodologies  (supported  by  commercial  tords)  for  potential  NATO  use. 

•  The  ISWG  task  the  AISG  to  develop  a  work  program  and  schedule  for  the  way  ahead 
for  ISWG  consideration. 

Each  of  the  three  papers  provided  in  the  1993  study  provided  data  and  analysis  of  issues 
for  integrating  structured  analysis  (e.g.,  data  flow  diagrams)  and  hierarchical  object-oriented 
design  (HOOD)  methods.  Among  die  tools  considered  (and  die  nations  submitting  die  data)  were 
the  following:  Concern  (FR),  IPSYS  (UK),  SELECT  (UK),  STOOD  (UK),  TEAMwork  (US), 
AdaNICE  (IT),  EPOS  (GE),  and  Virtual  Software  Factory  (VSF)  (DK). 

18.9.8  CCISs  for  NATO 

The  paper  CCIS  for  NATO:  Critical  Factors  Related  to  Implementation  of  an  Open 
Systems  Architecture  is  a  civil  (unsolicited)  contribution127  from  the  Armed  Forces 
Communications-Electronics  Association  (AFCEA)  to  NATO  that  contains  specific 
recommendations  on  standards  for  use  in  future  CCISs.  Its  genesis  was  to  contribute  to  the 
ongoing  debate  about  NATO  CCISs  in  general  and  about  the  ACE  ACCIS  program  (see 
Section  18.2)  in  particular.  The  central  theme  of  the  paper  is  to  present  the  case  of  an  open 
systems  architecture,  which  is  a  major  theme  of  WP  25  as  well.  The  paper  provides  rationale  for 
an  open  systems  architecture,  outlines  how  military  features  and  open  system  attributes  influence 


127  The  paper  was  prepared  wider  the  direction  of  senior  officer*  of  BoD,  Siemens,  and  Digital  and  a  review  board 
conrisdng  of  member*  of  AFCEA  who  have  (or  had)  sqtior/geoeml  officer  rank  in  NATO  aationt. 
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an  architecture,  presents  an  ACCIS  Reference  Model,  identifies  relevant  open  and  de  facto 
standards,  and  recommends  a  set  of  standards  applicable  for  an  open  systems  architecture  for 
NATO  CCISs. 

The  rationale  for  an  open  systems  architecture  may  be  summarized  by  the  following 
observations  made  in  the  paper. 

•  Ample  evidence  [is]  available  to  conclude  that  a  similar  architecture,  using  similar 
standards,  could  be  applied  for  both  management  information  systems  (MISs)  and 
CCISs. 

•  Security  and  performance  requirements  in  particular,  and  to  a  lesser  degree  the 
functional  requirements,  would  be  key  drivers  for  different  information  systems  under 
die  same  architecture. 

•  Use  of  die  open  system  architecture  approach  would  ensure  the  required  features  of 
interoperability,  scaleabihty,  compatibility,  and  portability  without  impacting  on  other 
facets  such  as  vendor  neutrality,  affordability,  and  the  fulfillment  of  essential 
requirements. 

The  AFCEA  Study  suggests  that  there  are  three  steps  in  specifying  CCISs  suitable  for 
NATO  (and  in  particular  for  an  ACE  ACCIS).  First,  strategic  goals,  generic  characteristics,  and 
system-specific  characteristics  are  transformed  into  an  ACCIS  Reference  Model,  which  identifies 
architectural  elements,  design  characteristics,  and  interfaces  between  functional  elements.  Second, 
standards  (and  some  “standard  products”)  are  selected  for  applicable  functional  elements  in  the 
ACCIS  Reference  Model  to  produce  an  ACCIS  architecture.  Third,  additional  products  are 
selected  in  accordance  with  standards  set  forth  in  the  architecture,  system-specific  development  is 
performed,  and  system  integration  is  conducted  to  produce  a  fieldable  configuration.  Note  that 
WP  25  identifies  standards  for  interfaces  and  architectural  elements  that  would  be  used  for  the  first 
two  steps.  (While  all  three  steps  will  be  taken  in  support  of  the  ATCCIS  Phase  III  Demonstration 
now  planned  for  September  1995,  it  is  outside  foe  scope  of  ATCCIS  to  select  products,  which  is  a 
national  prerogative.  A  single  common  configuration  is  nor  a  goal  for  ATCCIS — a  single  set  of 
standards  to  ensure  interoperability  is  a  goal  of  ATCCIS.) 

The  AFCEA  Study  cites  foe  US  DoD  Technical  Reference  Model  (TRM)  objectives  and 
principles12*  (similar  to  those  of  the  NATO  OSE  shown  in  Table  67  above)  as  reasonable 
objectives  for  foe  ACCIS  Reference  Model  and  revises  seven  of  the  principles  to  provide  a  set  of 
technical  means  for  reaching  foe  objectives. 

Figure  31  presents  foe  ACCIS  Reference  Model  proposed  for  NATO  in  the  AFCEA  Study 
paper.  It  consists  of  five  layers:  hardware,  operating  system,  common  services,  applications,  and 
user  interface.  The  common  services  are:  interoperability  services  [network  services  and 
application  profiles  for  file  transfer,  mess.  Tfi  transfer,  remote  login,  remote  application  execution, 
visual  display  unit  (VDU)  conversation,  d  tributed  file  system,  and  link  message  exchange];  data 
interchange;  data  management;  languages;  and  graphics  services.  Details  of  these  layers  are 
derived  from  foe  US  DoD  Technical  Reference  Model. 

Figure  32  presents  the  standards  recommended  for  the  ACCIS  Reference  Model.  These 
standards  form  the  recommended  open  system  architecture  for  ACCISs.  No  standards  are  needed 
for  hardware,  other  than  the  survivability  and  electromagnetic  shielding  that  would  be  specified  by 
existing  NATO  standards.  For  personal  computing,  the  Intel  X86  is  recommended  because  of  foe 

121  Apparently,  Version  1  (November  1991)  of  the  Technical  Reference  Model  was  used  in  the  AFCEA  Study. 
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numbers  of  COTS  applications  available.  Standardization  for  operating  systems  is  recommended 
to  be  built  on  standard  interfaces  between  the  operating  system  and  the  other  layers  in  die  AGCIS 
Reference  Model,  for  which  POSIX  (IEEE  103.x)  is  identified.  In  addition,  the  X/Open 
Portability  Guide  (XPG)  and  the  OSF  Level  Oast  release)  are  recommended.  For  personal 
computers,  MS-DOS  is  recommended  and  the  emerging  standard  New  Technology  (NT)  is 
highlighted  for  close  attention.  The  paper  clearly  states  that  no  standard  operating  system  is 
needed.  Rather,  the  best  platform  (operating  system  and  hardware)  should  be  selected  for  the 
system’s  mission. 
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Figure  31.  ACCIS  Reference  Model  Recommended  by  AFCEA  Study 
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Figure  32.  ACCIS  Reference  Model  Standards 

The  following  observations  are  made  for  the  ACCIS  Reference  Model: 

•  More  than  one  operating  system  is  to  be  expected  for  ACE  ACCISs.  Standardizing  on 
one  operating  system  for  a  angle  headquarters  is  seen  as  “highly  favorable  and  should 
be  pursued  to  the  maximum  extent”  The  AFCEA  Study  further  suggests  that  a  single 
operating  system  should  be  established  for  a  backbone  infrastructure  throughout  the 
headquarters.  (In  ATCCIS,  it  is  expected  that  dissimilar  hardware  platforms  may  be 
used  in  a  single  headquarters  and  that  more  than  one  operating  system  should  be 
supported  by  the  architecture — selection  of  hardware  and  operating  system  should 
remain  a  national  option,  and  common  local  area  network  standards  should  permit 
interoperability.) 

•  Users  should  be  permitted  (Remote  Application  Execution)  to  specify  that  an 
application  be  run  on  a  computer  other  than  the  user’s  workstation  but  residing  on  the 
same  local  or  wide  area  network.  (The  requirement  for  remote  processing  goes 
beyond  Basic  Interoperability — the  exchange  of  information  that  preserves  meaning 
and  relationships — and  is  therefore  not  inducted  in  the  ATCCIS  architecture. 
However,  remote  procedure  call  is  included  in  WP  25 — see  Section  9.11.3.5.) 

•  Users  should  be  able  to  conduct  VDU  Conversations,  in  which  a  user’s  input  on  a 
local  terminal  appears  as  output  on  other  terminals  connected  to  the  same  local  or  wide 
area  network. 

•  Users  should  be  able  to  treat  (some)  remote  files  as  if  they  were  local  files, 
independent  of  physical  location  on  a  local  area  network.  Remote  procedure  calls 
would  be  used  to  allow  separate  applications  to  exchange  data  structures  and 
commands  in  support  of  die  distributed  file  system  capability. 

•  Tactical  digital  information  links  (TADILs)  should  be  capable  of  being  exchanged 
across  local  and  wide  area  networks.  This  would  be  used,  for  example,  by 
applications  that  handle  a  recognized  air  picture  (RAP)  or  a  recognized  sea  picture 
(RSP). 
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•  The  need  for  logical  (conceptual)  data  models  is  recognized  for  data  management  but  is 
excluded  from  die  ACC3S  Reference  Model. 

•  A  single  access  protocol,  which  defines  how  data  are  returned  to  applications,  is 
needed  that  can  be  used  with  various  data  definition  languages  (DDLs)  and  data 
manipulation  languages  (DMLs)  for  different  types  of  file  systems.  Standard  DDL  and 
DML  (e.g.,  using  SQL)  would  mask  out  differences  among  vendor  database 
management  systems  (DBMSs)  and  make  applications  independent  of  a  particular 
DBMS  or  file  system. 

•  Two  types  of  distributed  database  models  are  noted  in  the  AFCEA  Study,  and.  a 
recommendation  is  made  that  one  should  be  chosen  as  the  best  basis  for  meeting 
operational  requirements.  (In  ATCCIS,  a  mixed  model  is  anticipated  that  combines 
both  of  die  concepts  noted  here.) 

(1)  Database  replication  duplicates  parts  of  a  local  database  to  a  remote  site.  Database 
replication  requires  a  universal  data  model  that  is  enforced  for  all  database 
segments  being  replicated.  Replication  is  triggered  on  updates  of  data  elements 
within  the  segment  of  the  database  being  replicated  or  on  a  periodic  basis. 
Applications  access  the  “copy”  that  is  stored  locally.  The  size  and  contents  of 
segments  being  replicated  depend  on  operational  requirements.  (In  ATCCIS,  this 
is  referred  to  as  a  partitioned,  partially  replicated  database.) 

(2)  Database  federation  uses  a  distributed  database  system  to  join  (or  federate) 
physically  separated  database  segments  into  a  virtually  seamless  global  database 
spanning  all  units.  The  size  and  contents  of  segments  being  federated  depend  on 
operational  requirements.  Database  federation  also  depends  on  a  universal  data 
model  that  is  enforced  for  all  segments.  In  its  pure  form,  there  is  only  one 
instance  of  data  (no  replication).  Applications  requesting  data  from  a  part  of  the 
federation  that  is  not  stored  locally  issues  a  request  via  the  networks  and  the  data 
are  returned  via  the  networks. 

•  The  applications  layer  of  the  ACCIS  Reference  Model  isolates  applications  from  the 
other  layers  to  facilitate  portability,  component  interchange,  and  reuse,  as  well  as  to 
allow  insertion  of  new  applications  without  disrupting  operations.  Applications 
exclusively  use  APIs  offered  by  the  common  services  and  user  interface  layers  (no 
application-to-application  integration  or  direct  data  exchange). 

•  The  user  interface  layer  is  defined  using  the  NIST  User  Interface  System  Reference 
Model  (see  Section  5.3). 

Nine  selection  criteria  are  identified  and  used  in  the  AFCEA  Study.  These  are:129 

•  Existing  hardware  and  software  (the  installed  base) 

•  Capability  to  provide  required  security  features 

•  Availability  of  standards  and  products 

•  Availability  of  COTS  products 

•  Capability  to  provide  the  needed  functionality 

•  Portability 

•  Scaleability,  enabling  the  same  applications  and  software  to  be  used  on  all  system 
classes  with  computer-specific  restrictions 

•  Interoperability  (defined  as  the  ability  to  share  data  and  functions  across  networks) 

•  Survivability  (to  include  real-time  update  of  databases). 


129  Standards  selection  criteria  have  not  yet  ben  addressed  in  this  paper.  Such  criteria  ate  the  subject  of  a  separate 
activity  in  ATCCIS  (Select  ATCCIS  Standards  and  Profiles).  See  the  ATCCIS  Phase  III  Work  Plan  [Ref. 
ATCCIS  19931. 
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19.  NATIONAL  INITIATIVES  FOR  MILITARY  USE  OF  OSI  STANDARDS 

This  chapter  identifies  national  initiatives  that  make  or 
plan  to  make  significant  use  of  OSI  standards  in  military 
applications.  Major  bilateral  and  multilateral  initiatives  are 
discussed  in  the  main  body  of  this  working  paper;  these  include 
the  Quadrilateral  Interoperability  Programme  (Section  18.6)  and 
STAMINA  (18.7). 

The  primary  purpose  of  this  review  of  national  initiatives 
is  to  identify  the  ways  in  which  military  features  are  being 
addressed  in  national  systems.  In  some  cases,  there  may  be 
fully-compliant  use  of  OSI  standards.  In  other  cases,  there  may 
be  defined  some  extensions  to  the  standards  that  could  be 
considered  by  international  bodies  as  candidates  for  new  options 
to  the  commercial  standards,  so  that  in  the  time  frame  of 
ATCCIS  (and  other  NATO  CCIS  projects)  the  military  features 
(e.g.,  a  secure  local  area  network)  may  be  specified  by  civil 
standards.  On  the  other  hand,  analysis  of  national  initiatives 
may  lead  to  conclusions  that  some  features  may  need  to  be 
specified  as  deviations  from  civil  standards  and,  in  these  cases, 
the  relevant  STANAGs  may  need  to  have  similar  deviations. 

National  initiatives  are  addressed,  where  possible,  in  terms  of  requirements,  profiles,  and 
transition  strategies  that  have  been  recommended  or  adopted.  A  short  review  is  provided  of  work 
being  done  to  evaluate  the  performance  of  civil  standards  for  military  applications.  Several 
initiatives  that  have  led  to  fielded  operational  capabilities  are  discussed  in  some  detail  in 
Appendix  C 

19.1  Canada 

Canada  is  participating  in  the  IGOSS,  which  will  serve  as  the  basis  for  Canadian  (and  US) 
GOSIP.  CA  GOSIP  will  be  promulgated  as  the  Canadian  Open  Systems  Application  Criteria 
(COSAC)  and  issued  as  a  Treasury  Board  Information  Technology  Standard  (TBITS).  [Ref. 
IGOSS  1993] 

Canada  has  been  conducting  testing  to  integrate  various  protocols  on  a  variety  of  systems, 
including  X.400  over  OSI  LANs,  OSI  applications  of  TCP/IP,  X.500  access  through  Internet,  and 
application  gateways  such  as  FTP-to-FTAM  running  on  a  SUN  workstation.  A  demonstration 
capability  developed  by  the  Canadian  Office  of  the  Director  General  Communications  and 
Electronics  Engineering  and  Maintenance  includes  tire  following  [Onufer  1992a]: 

•  OSI  LAN:  TP4,  CLNP,  ISO  8802-2,  ISO  8802-3 

•  OSI  applications  over  TCP/IP:  X.400,  X.500,  FTAM,  and  VT 

•  OSI  applications  over  X.25:  X.400  and  FTAM 

•  OSI/TCP  gateways:  SMTP-to-X.400,  X.400-to-SMTP,  FTP-to-FTAM,  and  FTAM- 
to-FTP 

•  TCP/IP  LAN. 
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Hie  Canadian  Army  is  replacing  its  present  tactical  communications  systems  in  the  near 
term  (1996-98  time  frame)  under  a  Tactical  Command  Control  Communications  System  (TCCCS) 
projc  :t  with  an  integrated  tactical  communications  system  called  Iris.  The  Iris  Radio  System  will 
provide  a  complete  family  of  modem  CNR  equipment  with  embedded  voice  and  data  encryption 
and  frequency  hopping  capabilities  in  the  VHF  band,  plus  specialized  AGA  and  combat  HF  radios 
for  all  vehicles  and  hand-carry  roles.  The  system  also  includes  local  area  systems  for  the 
headquarters,  a  trunk  system,  single-channel  radio  access  (SCRA)  facilities,  a  system-wide  tactical 
message  handling  system  (TMHS),  a  long-range  communications  system  (LRCS),  and  a 
management  system  for  both  the  communications  system  and  the  cryptographic  material  used  [Ref. 
German  1993]. 

The  Iris  architecture  includes  die  following  [Ref.  German  1993]: 

•  Local  Area  System  (LAS) — the  Headquarters  Information  Distribution  System 
(HIDS),  which  is  a  highly  modular  and  flexible  local  communication  system  with  a 
common  architecture  to  satisfy  the  requirements  of  headquarters  for  elements  ranging 
from  a  full  division  to  a  subunit  The  HIDS  provides  the  full  telephone  services  of  the 
EUROCOM  D/1  standard. 

•  Wide  Area  System  (WAS) — a  combination  of  the  Iris  trunk  system,  providing 
multichannel  line-of-sight  communications  for  voice  and  data;  and  the  LRCS, 
providing  satellite  and  high-power  HF  voice  and  data  communications  within  Iris  and 
with  external  systems.  In  the  Trunk  Distribution  Network  (TDN),  the  frame  relay 
service  is  replaced  by  an  ATM  cell  with  cell-head  forward  error  correction  (FEC). 
Data  uses  the  IP  protocol  overlaid  on  frame  relay  in  the  Local  Distribution  Network 
(LDN)  and  ATM  with  FEC  in  the  TDN.  Data  switching  is  done  by  IP  routers 
throughout  the  TDN,  the  LDN,  and  the  Mobile  System. 


•  Mobile  System — a  combination  of  the  CNR  suite  of  radios  and  the  SCRA  system  that  • 

includes  tactical  extension  nodes  (TENs)  to  provide  access  to  the  Iris  Trunk  System 
for  mobile  users  (packet  radio  is  not  provided,  but  the  TMHS  extends  throughout  Iris 
including  CNR  nets;  message  relaying  is  handled  at  the  applications  layer  within  the 
TMHS).  For  other  than  CNR  use,  TMHS  institutes  the  full  X.400  (1988)  suite  of 
service  and  offers  interface  to  ACP-127,  ACP-128,  and  JANAP-128-based  messaging 
systems;  to  Canadian  Forces  MMHSs,  and  selected  commercial  MHSs  through  a  * 

variety  of  gateways.  For  CNR  use,  TMHS  offers  a  subset  of  the  X.400  (1988) 
services,  together  with  the  capability  of  broadcasting  to  all  the  members  of  a  net 


•  System  Management  and  Control  System  (SMCS) — a  combination  of  the 
Communication  Management  System  (CMS)  providing  EUROCOM  D/0  and  OSI 
management  facilities,  and  the  Cryptographic  Material  Management  System  (CMMS) 
providing  management  and  distribution  facilities  for  all  the  key  material  and  equipment 
within  Iris. 


19.2  Denmark 

CCIS  Testbed.  During  the  period  1993-1993,  the  Danish  Army  will  be  developing  a  C2 
testbed  for  a  prototype  CCIS.  This  work  will  lead  to  an  implementation  of  an  Army  Command  and 
Control  System  in  1996.  The  current  C2  testbed,  which  has  been  on  trial  at  HQ/Jutland  Division 
and  which  will  be  introduced  in  1994  at  brigade  level,  consists  of  the  following  [Ref. 
DK  MOD  1994]: 

•  SUN/SPARC  servers  and  workstations 

•  UNIX  operating  system 

•  INGRES  database  management  system 
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•  Fairchild  Multimap  geographic  information  system  (GIS) 

•  UNIPLEX. 

Hie  testbed  uses  SUN  TCP/IP  over  an  Ethernet  LAN  running  at  2  Mbps  and  SUN  PPP  at 
9.6  kbit/s.  These  are  connected  to  the  national  field  trunk  network,  the  Danish  EUROCOM 
Communication  System  (DEOS). 

DEOS.  DEOS  is  a  EUROCOM  grid-area  communication  system  that  is  operational  from 
division  down  to  brigade  and  independent  battalion  echelons.  The  standards  of  the  tactical 
communications  network  of  the  Danish  Army  (DA)  are  based  on  EUROCOM  D/O  and  D/1  basic 
parameters.  DEOS  is  a  circuit-switched  trunk  node  network  (TNN)  used  primarily  as  a  voice 
network,  but  it  has  the  capability  for  data  communications.  The  nodes  are  connected  via  bulk- 
encrypted  line-of-sight  connections.  [Ref.  DK  MOD  1994] 

The  switches  in  the  network  can  be  used  to  interconnect  the  following  types  of  subscribers 
and  information  [Ref.  DK  MOD  1994]: 

•  Analog  PIT  (public  telephone  network) 

•  Analog  telephone  subscribers  (non-sec  ure) 

•  Digital  telephone  subscribers  (secure  to  the  SECRET  level) 

•  Facsimile  (secure  to  the  SECRET  level ) 

•  Teletype  (TTY) 

•  Data. 

The  DEOS  network  has  the  following  interfaces  [Ref.  DK  MOD  1994]: 

•  Connection  of  tactical  trunk  nodes  to  NATO  or  national  mobile  tactical,  fixed,  or 
strategic  networks,  using  multiple  STANAG  5040  (analog)  interfaces. 

•  Connection  of  tactical  trunk  nodes  to  die  national  PIT'. 

•  Connection  to  a  EUROCOM  network  via  a  EUROCOM  gateway.  For  the  subscribers 
numbering  plan,  DEOS  uses  STANAG  5046,  the  NATO  Military  Communication 
Directory  System. 

19.3  France 

Army  Tactical  CCIS  Systems.  Army  tactical  CCIS  systems  in  France  are  using  or  are 
projecting  to  use  more  and  more  components  based  on  OSI  standards.  The  Army  is  following  the 
general  recommendations  of  standards  organizations  such  as  AFNOR,  SPAG,  ITU-TS,  and 
CEN/CENELBC  (see  Appendix  F),  and  would  thereby  try  to  use,  wherever  possible,  the  products 
(hardware  and  software)  built  upon  these  standards. 

One  example  of  the  implementation  of  OSI  standards  in  Army  tactical  systems  is  the  use  of 
ETHERNET™  (ISO  8802.3)  to  link  cells  within  a  command  post  In  addition,  tactical  networks, 
such  as  RITA  and  RETIN  AT,  are  based  on  ITU-TS  X.25  packet  switched  standards.  Table  70 
identifies  the  international  OSI  standards  that  the  Army  intends  to  use  in  its  standardized  MHS 
Gateway,  based  on  QTIDP  specification. 

KETINAT.  RETINAT  is  a  data  communications  system  for  the  French  Army.  The 
network  operates  33  switches  of  two  types  (one  for  military  districts  and  one  for  military  regions). 
The  network  accommodates  1,400  synchronous  and  600  asynchronous  ports  and  supports  data 
rates  from  300  bps  to  64  Kbps.  The  switches  are  interconnected  with  64-Kbps  trunks  and  use 
X.75  gateways  for  interoperability  with  other  data  networks.  [Ref.  Cassese  1990] 
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Table  70.  French  Army  Standardized  MHS  Gateway 


081  Layar 

International  Standard 

Brlaf  Thin  of  Standard 

Application  (Layar  7) 

ITU-TS  X.400: 1864 

MHS 

ISO  0066/1:1967 

RTSE 

1800649:1086,180  0650:1986 

ACSE 

Praaantatton  (Layar  6) 

ITU-TS  X.400: 1904 

Abstract  Syntax  Notation 

Saaaion  (Layar  8) 

ISO  0326:1986,  ISO  8327:1986 

Basic  Sarvice  and  Protocol 

Transport  (Layar  4) 

ISO  8072:1985,  ISO  8073:1984 

Claat  2  Sarvica  and  Protocol 

Natwodc  (Layar  3) 

ISO  8208:1985 

Basic  Sarvica  and  Protocol 

Data  Unk  (Layar  2) 

ISO  7776:1985 

HDLCLAPB 

ITU-TS  X21:1 984 

Source:  [Romano  1092]. 


Real  Time  Transport  Service  (RTTS).  The  French  MOD  has  developed  an 
architecture  and  implementations  of  that  architecture  for  a  Real  Time  Transport  Service  (RTTS). 
GAM-T-103  is  a  specification  for  an  implementation  of  this  architecture.  [Ref.  GAM  1987] 
RTTS  results  from  more  than  IS  years  of  experience  in  the  design  and  realization  of  real-time  data 
networks  for  military  systems.  RTTS  provides  not  only  data  communication  services  but  also 
synchronization  and  management  services.  RTTS  was  described  at  the  June  1990  Military  OSI 
Symposium  at  STC.  [Ref.  STEI 1990]  The  paper  addressed  the  ISO  Transport  Service,  real-time 
constraints,  and  a  proposed  real-time  Transport  Service.  It  presented  the  classes  of  service,  the 
models  used  for  data  transfer,  the  connection-oriented  and  connectionless  modes  for 
communication  services,  the  synchronization  services,  and  the  management  services.  RTTS  has 
been  proposed  in  draft  STANAG  4254  (Annex  E)  as  the  basis  for  defining  real-time  services  for 
NATOCCISs. 

There  are  two  current  releases  of  the  Real  Time  Transfer  Protocol  specification: 

•  GAM-T-103B,  available  in  Rend)  only,  is  interfaced  with  a  data  link  service  near  to 
the  MAC  service  to  support  the  STANAG  1553  Military  Bus  (with  the  STANAG  391 J 
extension).  GAM-T-103B  is  used  for  the  Rafale  aircraft  weapon  and  navigation 
system. 

•  GAM-T-103C,  available  in  French  and  English,  is  interfaced  with  a  LLC1  data  link 
service  to  support  the  Recital  bus  (deterministic  Ethernet).  GAM-T-103C  is  used  for 
the  new  French  aircraft  carrier  weapon  and  navigation  system. 

Public  Message  System.  ATLAS  400  is  a  public  messaging  system  based  on  ITU-TS 
MHS  X.400-1984  and  is  a  good  illustration  of  the  national  implementation  of  X.400  standards. 
Administration  and  design  of  ATLAS  400  is  under  the  responsibility  of  TRANSPAC,  a  public 
company  that  is  a  subsidiary  of  FRANCE  TELECOM.  The  ATLAS  400  services  can  be  provided 
to  private  companies  or  administrations,  and  different  kinds  of  systems  can  be  built: 

•  A  large  company  can  get  its  own  “private”  messaging  system,  and  all  die  nodes  can  be 
split  throughout  the  country  at  the  different  company’s  locations. 

•  It  is  also  possible  to  get  a  system  that  allows  different  organizations  (public  or  private) 
to  exchange  messages  between  them.  This  can  be  useful,  for  example,  to  exchange 
documents  between  provider  and  client.  Such  an  implementation  would  be  used  to 
exchange  information  between  different  companies. 

ATLAS  400  is  only  an  interpersonal  messaging  system,  and  so  uses  only  the  Interpersonal 
Messaging  Protocol  from  the  X.400  Series.  ATLAS  400  can  also  be  adapted  to  the  size  of  the 
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company’s  computer  equipment  For  example,  the  Message  Transfer  Agent  may  be  locally 
implemented  or  derived  from  the  ATLAS  400  implementation.  Thus,  the  User  Agent  and  the 
Message  Transfer  Agent  are  not  necessarily  co-resident  This  illustrates  the  possibilities  of 
tailoring  the  system  to  client  use. 

SICF.  SICF  is  the  French  Army  battlefield  CCIS  designed  to  provide  ADP  facilities  at 
headquarters  at  Division,  Corps,  and  levels  at  field  Army  and  above  The  elements  of  SICF  are  the 
following : 

•  Functional  Units 

Each  command  post  has  several  computers  connected  to  a  LAN. 

Each  computer  can  serve: 

-  12  alphanumeric  terminals  in  any  chosen  role,  such  as  maneuver, 
intelligence,  or  logistics 

-  4  high-resolution  graphic  cells  for  maneuver  and  intelligence 

-  4-auto-dial  devices  linking  into  the  RITA  communications  network. 

Each  screen  can  play  any  role  for  the  user  (G2,  G3,  etc.). 

The  first-generation  uses  civil  hardware  protected  by  reinforced  boxes. 
Application  software  has  been  developed  in  C  language  and  uses  the  UNIX 
operating  system. 

•  Timescale 

First  generation 

1988  Stage — Army,  Corps  and  Rapid  Deployment  Force  HQ 

-  1990  Stage  2 — Down  to  division  level 

-  1991  Stage  3 — Additional  functions  such  as  command  post  flip  flop,  ISO 
communication  software  on  the  bases  of  the  Quadrilateral  Technical  Interface 
Design  Plan 

-  1994— Additional  logistics  functions 
Second  generation 

-  1996 — Integration  of  environment  constraints,  decision  supports,  and 
ruggedization. 

•  Functions 

Communications:  Computers  can  be  connected  to  those  at  other  command  posts 
to  exchange  data,  including  graphics,  via  RITA. 

User  Assistance:  Computer-assisted  message  preparation  for  LANDREP  and 
STANAG  5621/3624  messages;  message  transmission  via  RITA  and  distribution 
within  command  posts;  automatic  production  of  graphics  and  situation  reports 
from  stored  data. 

Database  Management*  Distributed  relational  database. 

Specific  functions:  nuclear,  biological,  and  chemical;  engineer,  intelligence; 
maneuver;  logistics;  fire  support  and  air-space  management 

Tactical  Profiles.  A  mixed  profile  has  been  defined  for  use  in  three  interoperable 
systems  in  France:  the  SIR  (Systeme  d’ Information  Regimen taire)  ABC,  the  LECLERC  tank,  and 
the  Tactical  Terminal  System  (TTGC),  each  being  developed  by  different  companies  with  different 
physical  architectures.  SIR  is  a  set  of  coherent  subsystems  adapted  to  a  wide  range  of  users  and 
platforms  (armor,  infantry,  engineers,  and  light  forces)  designed  to  pn  vide  advanced  voice  and 
data  communications  capability  to  the  regimental  units  on  the  battlefield.  SIR’S  Transmission 
Subsystem  provides  data  transmission  between  data  terminals  with  messaging  applications  as  well 
as  voice  communications.  SIR  ABC  is  the  SIR  subsystem  for  armor.  Its  data  terminals  are 
workstations  located  in  the  command  post  vehicles  at  regiment  and  squadron  level,  connected  by 
Ethernet  (ISO  8802-3)  within  each  vehicle.  Communications  between  vehicles  are  provided  by 
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VHF  combat  net  radio  based  on  the  PR4G  receiver.  SIR  ABC  must  interoperate  with  the 
messaging  system  of  the  LECLERC  tanks  and  with  tactical  data  terminals  of  the  support  vehicles. 
The  elements  of  SIR  ABC  are  [Ref.  Di  Pasquale  1993]: 

•  Radio  and  its  transmission  procedures 

•  Server  that  handles  the  interface  between  the  data  application  and  the  radio 

•  Data  application  that  processes  the  information  and  delivers  the  messages  to  the  server 
for  transmission. 

Two  transport  profiles  have  been  selected  for  SIR,  each  containing  a  new  transport 
standard  (ISO+)  to  support  point-to-multipoint  transmission:  (1)  mixed  profile,  adapted  to  a  mixed 
voice  and  data  transmission  protocol  of  the  PR4G;  and  (2)  TD  profile,  adapted  to  a  data-only 
transmission  protocol  (PAS)  of  the  PR4G.  The  services  and  protocols  for  these  profiles  are 
described  as  follows  [Ref.  Di  Pasquale  1993]: 

•  ISOf  is  a  connectionless-mode  service  offering  point-to-point  and  point-to-multipoint 
transfer  of  data  of  limited  size  with  selected  acknowledgments,  meaning  that  the  source 
entity  may  specify  which  destinations  are  required  to  acknowledge.  No  reordering  of 
transport  service  data  units  is  provided.  In  order  to  adapt  to  the  potentially  different 
underlying  network  layers,  die  ISOf  transport  layer  performs  TSDU  segmentation  and 
reassembly.  ISO+  is  derived  from  ISO  8602. 

•  The  network  layer  has  minimum  functionalities,  containing  a  null  version  of  ISO  8473 
(the  full  ISO  8473  layer  could  be  provided  if  and  when  necessary). 

•  The  lower  layer  of  the  TD  profile,  called  PAS,  is  a  PR4G  procedure  that  provides 
transmissions  of  a  maximum  of  512  bytes  to  one  or  more  users.  The  service  offered  is 
a  point-to-multipoint  or  broadcast  datagram.  It  is  accessed  through  die  Access  to  the 
PAS  Service  (APASS),  which  defines  how  the  PAS  procedure  is  used  in  the  profile. 

•  The  lower  layer  of  the  mixed  profile  is  call  Operational  Messaging  (OPM).  It  provides 
die  transmission  of  a  limited  number  of  bytes  (1,000  bytes  maximum)  using  the  OPM- 
message-transmission  and  TDMA  procedures  of  the  PR4G.  The  service  offered  is  a 
broadcast  datagram.  It  is  accessed  through  the  Access  to  the  OPM  Service  (AOPMS), 
which  defines  how  the  OPM  and  TDMA  procedures  are  used  in  the  profile. 

RA90.13*  The  RA90  communication  network  is  aimed  at  carrying  the  operational  and 
general-purpose  traffic  of  the  French  Air  Force.  It  forms  the  ground-ground  segment  of  the 
SCCOA  (Systeme  de  Condole  et  de  Commandement  des  Operations  Aeriennes),  the  French  part  of 
die  NATO  Air  Command  and  Control  System  (ACCS)  that  interconnects  entities  such  as  air  base 
local  area  networks  and  PABXs.  RA90  is  foreseen  to  be  the  backbone  of  the  future  French  joint 
transit  network  to  be  used  by  Army,  Navy,  Air  Force,  and  governmental  authorities  and  is 
expected  to  be  realized  under  the  control  of  DGA-STEI  (Service  Technique  de  1’Electronique  et  de 
rinformadque).  This  realization  took  the  benefits  of  the  already  operational  RAMSES  and 
TELEMAC  networks  that  have  validated  architecture  and  operational  concepts  based  on  a 
multiservice  capacity  using  ATM. 

RA90  includes  a  transit  network  interconnecting  LANs  and  MANs  of  the  Gendarmes,  Joint 
Staff,  Air  Force,  Army,  and  Navy.  The  basic  platform  (Thompac2G)  provides  such  services  as 
X.25,  LAPD,  binary  integrity,  SMDS  connectionless  server,  ATM  interfaces,  end-to-end 
transparent  data  links,  and  video  conference  (isochronous  interfaces). 


130  This  section  is  baaed  on  excerpts  from  [Monism  1993]. 
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French  military  initiatives  in  open  systems  environments  (OSEs).131  The 
first  attempt  to  use  OSE  concepts  in  military  programs  began  a  few  years  ago  during  die 
development  o  the  French  CCIS  SICF  by  an  intuitive  approach.  At  the  present  time,  the  French 
work  in  this  domain  consists  in  the  formalization  of  these  concepts  through  experimental  projects. 
The  aim  of  these  initiatives  is  to  favor  the  software  reusability  and  portability,  to  improve 
interoperability  between  basic  services  of  systems,  and  to  decrease  the  development  and  evolution 
costs. 

Those  projects  are  elaborated  around  the  concept  of  integration  infrastructure  (Structure 
d’Accueil),  reusable  in  any  CCIS  realization  (see  Figure  33).  It  is  a  Generic  Kernel  that  provides  a 
set  of  programming  interfaces  and  enables  an  easy  integration  of  specific  operational  applications  in 
CCISs.  The  two  main  experimental  projects  are  briefly  described  in  the  following  paragraphs. 


BDSIC  Project.  The  aim  of  this  project  is  to  demonstrate  the  operational  interest  of  such 
a  structure  within  die  context  of  COS  developments.  The  prototype  realization  is  based  on  die 
following  research  areas: 

•  Development  of  structured  data  management  services  that  are  independent  of 
operational  applications  (e.g.,  thematic  research) 

•  Internal  interoperability  between  distinct  functional  entities 

•  External  interoperability  with  heterogeneous  databases 

•  Security  management 

•  Enhancement  of  database  management  system  services  (e.g.,  data  dictionary). 


The  elaboration  of  a  Generalized  Data  Dictionary  satisfies  an  operational  need  for  data  model 
harmonization  within  the  CCIS. 


ISOTROPE  Project  ISOTROPE  is  a  leading  project  that  is  managed  in  coordination 
with  several  studies,  particularly  with  the  BDSIC  project  Its  purpose  is  to  harmonize  and 
standardize  the  concept  of  Integration  Infrastructure.  This  approach  is  based,  cm  die  one  hand, 
upon  the  existence  of  COTS  products  that  implement  standards  offering  good  guarantees  of 
evolution;  and,  on  the  other  hand,  upon  the  provision  of  common  services  among  CCIS 
applications.  In  this  architecture,  two  software  layers  have  been  defined  (see  Figure  33  above): 


131  The  remaining  paragraphs  of  this  section  are  bated  on  an  informal  communication  from  the  French  delegation 
to  the  January-Fcbruary  1994  ATCC1S  PWG. 
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one  is  oriented  on  common  technical  services  and  die  other  is  oriented  on  operational  applications. 
These  two  parts  of  the  architecture  may  be  described  as  follows: 

•  Integration  Infrastructure.  As  illustrated  in  Figure  33  (above),  the  Integration 
Infrastructure  offers  a  set  of  standardized  services  in  data  management, 
communication,  security,  and  system  management  It  is  composed  of  the  following: 

A  COTS  product  sublayer,  which  enables  a  CCIS  project  to  limit  the  development 
costs  and  to  ensure  the  evolution  of  systems 

A  kernel  sublayer,  based  on  the  one  above,  which  offers  a  standardized  interface 
for  operational  applications.  This  interface  enables  the  independent  evolution  of 
applications  and  COTS  products  and  favors  applications  interoperability. 

•  Application  Level.  The  application  level  is  above  the  Integration  Infrastructure  and 
comprises  two  different  types  of  applications: 

Generic  applications,  which  are  the  common  basis  of  CCISs  (e.g.,  MHS, 
documentation  management) 

Specific  applications,  which  are  adapted  to  particular  operational  needs  and  which 
are  based  on  the  Integration  Infrastructure  services  and  on  the  generic  applications 
when  needed. 

19.4  Germany 

HEROS-2/1  is  the  German  Army  CCIS  that  supports  staff  work  at  the  corps,  division, 
brigade,  and  battalion  echelons. 

HEROS  Functional  Units.  The  core  of  this  system  comprises  the 
computer/communications  cabins  (RKK)  and  the  graphics  cabins  (GIK),  which  are  installed  in 
shelters,  thus  making  them  fully  mobile.  The  command  post  can  be  configured  for  specific 
echelons.  They  are  interconnected  via  a  Local  Area  Network  (LAN)  allowing  command  post 
workstations  (GAP)  with  multi-terminal  computers  to  be  linked  at  remote  locations. 

For  use  at  the  battalion  level,  the  functionality  of  the  RKK  and  the  GAP  is  combined  in  a 
communication-capable  command  post  workstation  (GAP-C),  thereby  providing  leanness.  The 
GAP  uses  a  UNIX-based  processing  unit  with  a  Rise  3000  processor,  three  MS-DOS  user 
terminals  (X-Terminal  423  with  Intel  486  at  23  MHz);  and  a  printer,  with  fiber-optic  cable 
connection  and  modem  to  support  an  ISO  8802-3  local  area  network.  The  GAP-C  will  augment 
the  GAP  equipment  with  communication  interfaces  to  interface  to  the  existing  Wide  Area  Network 
(WAN)  and  VHF-radio.  The  RKK  has  a  UNIX-based  Rise  3000  processor,  two  terminals  for 
system  administration,  and  additional  communications  (e.g.,  modems  and  encryption  devices  to 
support  1,000  m  of  fiber  optic  cables  interconnecting  GAP  and  GAP-C  facilities).  Most  of  the 
hardware  and  software  components  used  are  COTS  products. 

Each  command  post  can  be  duplicated  in  order  to  provide  to  the  commander  high 
availability  of  the  system  and  to  support  the  leap-frogging  concept  Each  workstation  can  (day  any 
role  for  the  user  (G2,  G3,  etc.).  Communications  to  die  command  posts  arc  provided  by  wide  area 
networks. 

HEROS  Functions.  All  GAPs  are  capable  of  handling  and  displaying  graphical  military 
situations/operational  plans  in  front  of  digital  military  maps  (overlay  technique).  Formatted 
messages  can  be  displayed  automatically  in  a  graphic  form  using  NATO  Standard  Tactical 
Symbols.  Vice  versa,  tactical  symbols/situations  or  operational  plans  generated  graphically  by  the 
user  can  be  transformed  automatically  into  formatted  messages/texts.  The  structure  of  individual 
"standard  situations"  can  be  defined  by  the  user,  the  content  of  which  will  be  extracted 
automatically  from  the  actual  central  command  post  database.  The  staffs  of  corps,  division,  and 
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brigade  echelons  are  also  equipped  with  graphic  shelters  (GKs).  The  GK  contains  a  workstation 
and  rfigitijang  equipment  with  which  operational  plans  can  be  drawn  on  a  military  paper  map  in 
large  format  and  fed  into  the  system  for  further  processing.  An  AO-plotter  within  die  GK  allows 
for  the  plotting  of  any  graphical  situation  displayed. 

HEROS  Applications.  The  HEROS  applications  include  handling  of  the  following: 

•  Message  formats  according  to  STANAG  5500 

•  Message  reporting  based  on  STANAG  5621 

•  Orders  according  to  STANAG  2014 

•  Tables 

•  Graphical  situations/operational  plans 

•  Military  Message  Handling  System 

•  MMI  (X-Windows,  OSF/Motif). 

HEROS  also  includes  a  communications  architecture  that  allows  the  automatic  use  of  die 
following  communication  links: 

•  LAN  (command  post  communication) 

•  WAN  interconnections 

Bundeswehrgrundnetz  (connection  to  the  Army  Staff  and  NATO) 

AutoKo  (connection  to  corps,  division,  and  brigade) 

VHF  Radio  (connection  to  battalions  and  other  command  posts) 

QIP-Interface  (connection  to  MCS,  SICF,  and  WAVELL) 

SATCOM  (INMARSAT,  INTELSAT)  for  out-of-area  deployment. 

HEROS  Database  Management  Besides  other  data  areas,  each  command  post  has 
available  a  central,  actual,  and  consistent  database  that  is  continually  updated  by  the  users 
according  to  the  occurring  events.  For  redundancy  and  leap-frogging  purposes,  this  database  can 
be  duplicated  within  a  command  post  In  this  case,  both  databases  are  held  on  the  same 
information  level  automatically. 

HEROS  Time  Scales.  Field  trials  during  3Q  1989  to  4Q  1990.  Procurement/fielding 
in  three  lots  (due  to  fund  limitations).  First  lot  under  contract  for  fielding  of  the  bulk  of  Crisis 
Reaction  Forces  including  multinational  staffs  [e.g.,  EUROCORPS,  GE/NL  corps,  MND(C)] 
during  1994  to  1997.  The  remainder  of  Crisis  Reaction  Forces  and  the  Main  Defence  Forces  are 
planned  to  be  fielded  by  the  second  and  third  lot  during  1998  to  2000. 

ISDN  Implementation.133  The  German  Armed  Forces  decided  in  1989  to  implement 
an  ISDN  network  exclusively  for  their  own  use.  Work  is  underway  to  integrate  ISDN  switches 
for  this  network,  called  the  ISDN  for  the  German  Armed  Forces  (ISDN-BW).  This  network  will 
provide  digital  connections  between  all  digital  end  users,  different  services  at  one  service  point 
with  a  universal  interface,  and  integration  of  new  services.  A  migration  concept  is  based  on  the 
strategy  to  replace,  step  by  step,  the  analog  switches  in  die  network  by  digital  switching 
technology.  These  digital  islands  will  then  be  connected  with  digital  transmission  links  to  the 
ISDN-BW. 

Alcatel  has  proposed  an  implementation  for  ISDN-BW  based  on  commercial  off-the-shelf 
products  used  in  the  German  PTT.  Elements  of  this  implementation  include:  Special  Network 
Exchange  (SNE),  supporting  up  to  19,000  analog  and  8,500  digital  subscribers;  Special  Network 

132  TMs  section  is  based  on  excerpts  from  [Strobe]  1993], 
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Exchange-Small  (SNES);  Special  Network  Concentrator  (SNC);  Special  Network  Operation;  and 
Maintenance  Crater  (SNO),  and  PCM30  multiplexer.  The  multiplexer  will  have  special  signalling 
converters  (KZUs)  for  conversion  from  analog  to  digital  signalling  procedures. 

Messaging.  A  small  team  at  Forschungsinstitut  fllr  Funk  und  Mathematik  (FFM) 
implemented  a  Message  Store  (MS)  conformant  to  the  CCITT  Recommendation  X.40Q/1988, 
including  an  X-Window-Based  Remote  User  Agent  (XRUA)  and  a  flexible  interface  of  the  access 
to  the  MS  services.  Applying  an  MS,  the  User  Agent  (UA)  of  a  Military  Message  Handling 
System  (MMHS)  can  run  on  a  small  computer  because  there  is  no  Message  Transfer  Agent  (MTA) 
needed.  The  MS  releases  the  User  Agent  (UA)  from  the  need  of  24-hour  availability.  The  system 
presented  will  be  used  for  the  implementation  of  military  enhancements  and  it  is  part  of  the  German 
contribution  to  the  NATO  project  CNSI  (Communication  Systems  Network  Interoperability)  of 
Subgroup  9.  [Ref.  Haak  1993] 

19.5  The  Netherlands133 

ZODIAC.  The  Zone  Digital  Automatic  Cryptographic  (ZODIAC)  network  is  the  tactical 
communications  network  of  the  Royal  Netherlands  Army  (RNLA),  whose  standards  are  based  on 
EUROCOM  D/1  basic  parameters  [Ref.  EUROCOM  D/1  1986].  ZODIAC  is  a  circuit-switched 
trunk-node  network  (TNN)  used  primarily  as  a  voice  network  but  it  has  the  capability  for  data 
communications.  The  nodes  are  connected  via  line-of-sight  connections.  Networks  identified  as 
potentially  suitable  for  connection  to  ZODIAC  are  the  following  [Langeveld  1993]: 

•  Analog  PTT  networks  [public  switched  telephone  network  (PSTN)] 

•  DataNetl  (NL  packet  switched  data  network) 

•  Group  Special  Mobile  (GSM)  network  (car  telephone  network) 

•  ISDN  and  Internet 

•  Netherlands  Armed  Forces  Integrated  Network  (NAFIN),  the  NL  future  strategic 
network,  with  possible  ISDN  access  capabilities. 

The  evolution  planned  for  ZODIAC  is  die  direction  of  the  NATO  Tactical  Communications 
Architecture  being  developed  by  TSGCE  PG6.  The  requirements  of  this  architecture  include  the 
following  [ATCA  MC277/2  1990]: 

•  Connection  of  a  tactical  trunk  node  to  a  NATO  or  national  fixed  or  strategic  network, 
using  multiple  STANAG  5040  (analog)  interfaces  or,  if  both  the  networks  are  digital, 
the  use  of  the  NATO  Multi-Channel  Digital  Gateway  (STANAGs  4206-4213).  This 
connection  must  allow  transit  as  well  as  access  connections  through  the  network. 

•  Connection  of  a  tactical  trunk  node  to  a  (national  PTT)  PSTN. 

The  NATO  requirements  document  [ATCA  MC277/2  1990]  describes  only  the  NATO 
interconnection  needs  (both  access  and  transit)  of  tactical  networks.  It  does  not  specify  the 
protocols  or  mechanisms  needed  at  the  strategic  or  post-telephone-telegraph  (PTT)  side  to  realize 
the  interconnections.  [Ref.  Langeveld  1993]' 

The  ZODIAC  network  has  several  interfaces  available  for  interconnection  with  other 
(tactical)  networks.  These  include  a  EUROCOM  gateway  for  interface  to  the  EUROCOM  network; 
an  international  access  link  (IAL)  for  interface  to  EUROCOM  equipment;  STANAG  5050  and 
STANAG  4206-4213  gateways  for  interfaces  to  non-EUROCOM  networks;  and  an  LI  interface 


133  TOs  section  is  primarily  based  on  [ftast  1994]. 
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(currently  a  modification  of  STANAG  5050,  as  this  interface  is  not  yet  defined  by  EUROCOM)  to 
the  PTT  network.  [Ref.  Langeveld  1993] 

The  RNLA  is  investigating  a  ZODIAC-ISDN  gateway  interface  based,  in  part,  on 
STANAGs  4206-4213.  ISDN  is  not  yet  fully  operational  in  the  NL  PTT,  but  there  is  a  pilot 
project  interconnecting  several  Dutch  cities.  The  gateway  is  focused  on  the  time-division 
multiplexing  (TDM)  primary  rate  access  (European)  standard  of  2.048  Mbps  (30B+D),  the  64- 
kbps,  8-bit  pulse-mode  modulation  A- Law  (European)  and  u-LAW  (US)  standard  speech  coding, 
LAPD,  1.441  (Q.921),  and  1.451  (Q.931).  The  scope  of  the  required  gateway  conversions  is 
indicated  by  Table  71.  EUROCOM  uses  multiple  sampling  and  majority  voting  (MSMV)  and 
block-code  forward  error  correction  (FEC)  for  data  communications.  For  its  subscriber  numbering 
plan,  ZODIAC  uses  STANAG  5046  (The  NATO  Military  Communication  Directory  System), 
STANAG  4211  ( System  Control  Standards ),  and  STANAG  4214  (Directory  for  Tactical 
Communication  Systems),  whereas  the  ITU-TS  numbering  plan  is  based  on  E.163  (Q.ll), 
Numbering  Plan  for  die  International  Telephone  Services,  E.  164  (1.331),  Numbering  Plan  for  die 
ISDN  Era,  and  1.330,  Numbering  Addressing  and  Routing.  A  study  by  RNLA  has  concluded  that 
a  ZODIAC-ISDN  based  on  STANAGs  4206-4213  is  feasible  and  may  be  used  to  interconnect 
other  networks,  such  tactical-to-FDDI  networks.  However,  since  the  STANAG  4206-series 
interface  was  originally  developed  for  a  tactical  gateway,  some  changes  (e.g.,  the  possibility  to 
exchange  signalling  information  before  traffic  mode  is  reached)  in  the  existing  STANAGs  may  be 
necessary  to  make  the  interface  useful.  [Ref.  Langeveld  1993] 


Table  71.  Overview  of  ZODIAC-ISDN  Gateway  Converaiona 


Conversion  Type 


Trunk  Speed  M 
Speech Coding" 


Protocol 


beta  Communication 


Security 


- totilht - 

(EUROCOM -based) 


256  kbps 
Oaks  Modulation 

STANAG  4214 


STANAGs  4207,  4208 
MSMV/FEC 


.Vi'TT. 


ISDN  (PSTN/Strateglc) 


2048  kbps 
PC*i(A-[sw) 


1.330 

Q.B21 


Asynchronous/Synchronous 


Source:  (Langeveld  1083]. 


Message  Transfer  System  (MTS).  In  December  1994,  the  new  MTS  will  be  fielded, 
upgrading  the  present  store-and-forward  system  for  teletype  messages.  The  MTS  will  make  full 
use  of  the  ZODIAC  infrastructure,  with  the  added  benefit  of  error-firee  data  transmission. 
Although  primarily  intended  to  handle  the  voluminous  ACP-127  teletype  traffic,  it  will  also 
comfortably  handle  file  transfer.  The  relation  of  MTS  to  ZODIAC  is  illustrated  in  Figure  34.  To 
guarantee  delivery  of  all  messages  accepted  for  transmission,  the  messages  are  replicated  to  a 
maximum  of  three  other  message  switches  using  the  ZODIAC  network. 

The  following  comments  on  standards  apply  to  the  MTS: 

•  Standard  X.400  does  not  meet  the  military  requirements  for  priority  and  security 
levels,  compatibility  with  ACP  127  and  military  addressing.  A  set  of  protocols,  based 
on  X-400  and  designed  to  be  used  over  die  EUROCOM -com  pliant  ZODIAC  network, 
was  developed. 

•  LKBP  is  an  application  layer  Message  Handling  protocol,  based  on  STANAG  4406 
(military  extensions  of  X.400).  Gateways  will  handle  communication  with  non- 
LKBP  systems,  including  conversion  of  ACP-127  messages. 
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*  LKDP  is  a  protocols  stack  covering  OSI  Layers  1  through  6  in  the  ZODIAC 
environment. 

*  COTS  products  covering  formal  and  de  facto  standards  are  used  where  possible. 
HDLC,  for  instance,  is  used  to  ensure  error-free  transmission  of  text  and  data. 

*  The  MTS  has  been  designed  to  effect  a  transition  to  X.400,  if  and  when  necessary, 
with  minimal  effort 


Some*:  [Prast  1994], 

Figure  34.  UTS  Employment  In  Zodiac 


System  Control  and  Management  (SYSCOM).  SYSCOM  supports  the 
management  of  the  RNLA  ZODIAC  communications  system.  The  management  of  ZODIAC  has 
been  divided  into  the  three  hierarchical  levels  identified  by  EUROCOM,  with  an  extra  coordinating 
layer  for  Signals  Regiment  Operations.  The  main  functions  of  die  S Y  SCOM-network  have  been 
allocated  to  the  following  roles  (see  Figure  35): 

•  System  Execution  and  Planning  (SEP) — supporting  for  operational  planning:  overall 
management  of  frequencies: 

•  Coordinating  Operational  System  Control  (COSC) — allocating  resources 

•  Operational  System  Control  (OSC) — managing  operational  units  and  equipment, 
performing  frequency  calculations,  and  managing  communications  links 

•  Facilities  Control  (PC). 


8ouror.  [Prast  1904]. 

Figure  3S.  System  Control  and  Management 
in  Zodiac 
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All  SYSCOM  hardware  and  software  configurations  are  identical.  A  system  can  thus 
support  any  role  at  any  level.  A  subset  of  the  functionality  is  made  available  to  the  user,  depending 
on  the  role  and  the  hierarchical  level  of  the  unit  at  that  time.  Because  changes  in  data  repbeated  to 
all  other  cells,  every  cell  can  take  over  any  SYSCOM  role  at  any  level  at  all  times. 

Hie  following  comments  on  standards  apply: 

•  Because  the  SYSCOM  system  uses  the  ZODIAC  network,  communications  must  meet 
the  requirements  of  the  EUROCOM  standards  DO  and  Dl. 

•  The  original  plan  was  to  link  the  SYSCOM  cells  using  X.25  for  Layers  1-3.  Because 
of  problems  with  the  COTS  software,  TCP/IP  over  DECNET  is  used  in  the 
operational  system. 

Message  Terminal  (MT).  The  MT  will  be  fielded  in  September  1994,  replacing  the 
current  Personal  Computer  Teletype  (FCT).  It  combines  the  functionality  of  the  X.400  User  Agent 
(to  edit,  send,  receive,  store,  and  manage  messages)  with  that  of  a  standard  (portable)  office 
personal  computer.  It  can  also  function  as  an  Access  Unit  for  teletype  messages. 

Since  the  MT  will  be  deployed  in  national  and  multinational  (NATO  and  UN)  operations, 
the  MT  user  interface  has  been  written  in  English.  For  the  same  reason,  the  MT  supports  both 
ACP-127  and  LKBP/LKDP.  It  is  also  possible  to  edit  a  free-format  header  to  suit  other  standards. 

In  the  ZODIAC  environment,  the  MT  is  connected  to  the  data  port  of  the  secure  telephone. 
Messages  and  data  can  be  sent  point-to-point  or  via  the  MTS  store-and-forward  system.  In  other 
environments,  point-to-point  links  can  be  established  via  PTT  or  SATCOM,  using  modems. 
Equipment  for  on-line  encryption  can  be  added  if  required.  The  role  of  the  MT  in  ZODIAC  is 
illustrated  in  Figure  36. 


Sourcv:  [Prut  1994]. 

Figure  36.  Role  of  Message  Terminal  (MT)  in 
Zodiac 

The  following  comments  on  standards  apply: 

•  The  MT  uses  the  X.400- based  LKBP  and  the  EUROCOM-compliant  LKDP  in  the 
ZODIAC  environment. 

•  Elsewhere,  the  MT  supports  ACP-127  over  ITU-T'S  V.24/V.28  links. 

•  MS-Windows  provides  the  required  multi-tasking  capabilities  on  an  Intel  platform,  as 
well  as  the  graphical  user  interface. 

CC1S  Program  Evolution:  Software.  The  RNLA  has  substantial  in-house  software 
development  resources.  Its  in-house  capability  has  been  involved  in  C2-related  projects  for  a 
number  of  years,  in  the  roles  of  technical  authority,  sub-contractor,  or  main  contractor. 
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One  of  the  key  projects  is  the  development  of  a  prototype  CCIS  for  brigade-level  to  corps- 
level  headquarters  (see  Figure  37).  Initially,  its  main  function  is  to  create  a  common  “information 
base”,  both  within  a  headquarters  and  across  unit  boundaries,  that  is  readily  accessible.  Read  and 
write  access  is  through  a  Windows-Icons-Menus-Pointer  (WIMP)  user  interface  over  a  map 
background.  Information  on  a  unit's  location,  status,  plans,  and  holdings  is  represented  in 
standard  military  symbology,  with  additional  alphanumeric  data  only  a  mouse  click  away.  Color 
codes,  warning  messages,  and  a  high  proportion  of  user-selectable  view  options  help  to  fulfill  an 
individual  user's  information  requirements.  High-quality  overhead  projection  supports  briefing 
and  presentations.  Within  an  HQ,  the  workstations  in  cells  are  connected  via  an  Ethernet  LAN. 
Using  point-to-point  data  links  over  the  ZODIAC  network,  data  is  replicated  to  other  HQs. 


Figure  37.  Support  of  Division  and  Brlgado 
Echelons  In  ZODIAC 


Experiences  with  several  iterations  of  the  prototype  on  maneuvers  have  shown  the  concept 
to  be  viable.  The  intention  is  to  validate  it  formally,  convert  it  to  the  ATCCIS  architecture,  and 
then  to  field  an  implementation  of  the  core  capability.  The  hardware  and  software  architectures  ^ 

have  sufficient  flexibility  to  be  able  to  add  functionality  when  necessary.  The  present  prototype 
will  be  the  point  of  departure  for  the  development  of  the  RNLA  contribution  to  the  ATCCIS 
Phase  in  demonstrator  in  1995.  For  the  prototype,  de  facto  standards  supported  by  COTS 
products  on  the  current  hardware  platform  (Sun  workstations)  have  been  used:  TCP/IP  over 
Ethernet,  GKS,  Open  Look,  and  SQL.  The  ATCCIS  architecture  and  die  OSE  model  are  expected  ^ 

to  influence  the  final  implementation  considerably. 

CCIS  Program  Evolution:  Platform.  Fully  functional  CCISs  perform  a  common 
set  of  tasks  for  all  users  and  provide  additional  functionality  depending  on  role  and  mission.  The 
current  political  situation  has  led  the  Dutch  Government  to  task  the  RNLA  with  a  variety  of  roles 
and  missions  that  call  for  a  flexible  Army  and,  consequently,  also  requires  great  flexibility  in  its  q 

CCIS. 

A  fully  functional  CCIS  also  needs  a  substantial  amount  of  computing  power  for  a  variety 
of  tasks:  transactions  on  sizable  databases,  graphical  user  interface,  raster  and  vector  geographical 
data,  processing  for  complex  algorithms,  and  local  and  wide  area  network  connections. 

To  be  able  to  meet  these  requirements,  the  RNLA  has  developed  the  concept  of  a  highly  # 

modular  Universal  C2  Workstation  (see  Figure  38).  Based  on  the  OSE  and  the  ATCCIS 
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architecture,  these  workstations  and  the  CCIS  they  are  part  of  will  provide  a  common  core 
database,  applications,  and  communications  facilities.  Additional  capabilities  can  be  for 
specific  mission  or  needs  of  a  subfunctional  area  on  a  temporary  or  permanent  basis. 


Sourca:  [Pratt  1094]. 

Figure  38.  Architecture  for  Universal  C2 
Workstation 


Geographical  information  plays  a  crucial  part  in  a  CCIS.  The  system  must  be  able  to 
function  with  a  minimum  of  raster  data,  providing  more  functionality  when  more  data  becomes 
available.  DIGEST  is  at  present  the  preferred  format  for  acquisition  of  digital  terrain  data,  while 
others  are  under  consideration. 

COTS  products,  based  on  international  standards,  will  be  used  for  implementation  of  the 
concept  Fielding  is  expected  in  1996.  The  RNLA  is  committed  to  use  the  work  of  civil  and 
NATO  standards  organizations  where  possible. 

19.6  The  Netherlands,  Norway,  France,  United  Kingdom 

Four  NATO  nations  are  participating  in  a  project  entitled  "Cooperative  Prefeasibility 
Studies  for  Tactical  Communications  Systems  for  the  Land  Combat  Zone — Post  2000."  In  this 
study,  candidate  subsystem  architectures  are  being  developed  on  the  basis  of  current  and  near 
future  communications  technologies  as  ISDN,  EUROCOM,  FDDI,  PABX,  packet  radio  and 
cellular  telephony.  From  these  technologies  six  subsystem  architecture  alternatives  were  derived 
each  with  either  a  nodal  (centralized)  or  a  nodeless  (distributed)  characteristic. 

From  this  set,  subsystem  architectures  are  selected  on  the  basis  of  military  operational 
requirements  and  threat  expectations  to  form  one  system  architecture  for  the  entire  Land  Combat 
Zone.  The  chosen  system  architecture  to  cover  the  intermediate  and  the  rear  zone  of  the  land 
combat  zone.  The  wide  area  communications  subsystem  consists  of  a  backbone  of  distributed 
Local  Area  Communications  Subsystem  (LACS)  elements  with  centralized  LACS  elements 
providing  access  to  the  backbone.  [Ref.  van  der  Voort  1990] 

19.7  Norway 

TADKOM.134  TADKOM  is  the  Norwegian  tactical  area  communications  system.  The 
packet  radio  segment  for  TADKOM  will  be  the  multi-role  radio  (MRR).  The  Norwegian  Defence 
Digital  Network  (NDDN)  is  the  Norwegian  strategic  network.  Compatible  services  for  NDDN  for 


134  TUs  section  is  based  on  excerpts  from  [Knuuea  1993], 
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the  tactical  area  are  under  study.  X.400  (1988)  and  ACP-127  message  handling  are  already  in 
operation  for  NDDN.  This  capability  has  been  updated  to  conform  with  MMHS-88  (STANAG 
4406).  In  the  future,  tactical  message  switches  (TMSs)  will  be  installed  in  command  posts,  where 
there  will  be  operator  positions  for  management  of  the  tactical  MHS  as  well  as  for  traffic  handling. 
The  TMS  will  contain  functions  to  support  message  handling  services  for  packet  radio  subscribers. 
X.25  and  circuit-switched  connections  are  planned.  There  will  be  an  extension  of  S.25  for 
connectionless  data  units  in  TADKOM. 

The  radio  units  in  the  MRR  will  be  called  tactical  multirole  radios  (TRRs).  The  TRR  will 
be  used  in  two  applications:  tactical  radio  access  system  (TRAS)  and  combat  net  radio  (CNR). 
The  TRR  provides  access  to  voice  (16-kbps  CVSD)  and  data  services  (packet  data  using  S.25  with 
extensions  for  connectionless  transmission).  Protocols  for  Layers  1-3  for  CNR  and  TRAS  will  be 
only  slightly  different  and  offer  the  same  services  to  the  higher  layers. 

The  use  of  MMHS  and  protocols  identified  above  is  expected  to  meet  interoperability 
requirements  and  support  efficient  use  of  radio  bandwidth.  The  proposed  protocols  support  both 
radio  silence  and  periodic  unavailability  by  means  of  a  message  store  and  letting  the  radio  choose 
when  and  what  to  send  and  receive.  For  short  messages,  which  are  very  important  in  a  tactical 
environment,  the  reduction  in  overhead  compared  to  full  X.400  is  expected  to  be  at  least  10:1. 
This  is  mainly  the  result  of  transmitting  only  required  information  associated  with  the  X.400 
protocols,  leaving  out  Layers  4-6  to  reduce  both  the  number  of  bits  sent  and  the  delay. 

19.8  Spain 

Spain.  The  SP  MOD  is  using  and  is  projecting  to  use  more  and  more  components  based 
on  OSI  standards.  Support  of  the  SP  Defence  C3  Systran  currently  consists  of  the  following: 

•  Hardware: 

-  Workstation  Digital  (MICROVAX) 

Servers  (Tektronics) 

PC-compatible  workstations 

•  Software: 

Digital/VMS 

Tektronics/UNIX  (System  V) 

PC  Compatible/SCO  Open 

-  X-Windows,  Motif,  MS-Windows  3. 1 
AD  ABAS  database  management  system 
ACP-127  formatted  messages. 

•  Internal  communications: 

-  Ethernet  (ISO  8802-3) 

TCP/IP  and  DECNET  protocols 

•  Communications  system  standards: 

-  FAX/tele  phone — PTT  (PSTN)  and  PSN 

Data  net  interface— X-25 

Protocol — LAP-B 

-  Connection  of  PSTN-DSN— X-28  and  X-32 

-  Messaging— ACP-127 

Messaging  upgrade — X-400  with  ACP-127  gateway  and  MHS  (X.400: 1988). 
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19.9  United  Kingdom 

Robust  Protocols  Research  Programme.  The  UK  MOD  and  NATO  has  established 
the  Robust  Protocols  Research  Programme  at  Defence  Research  Agency  to  quantify  and  minimize 
the  risks  associated  with  the  UK  MOD  and  NATO  policies  for  procuring  future  CCISs  to  ISO  OSI 
standards.  The  approach  being  taken  is  to  take  commercial  off-the-shelf  protocols  that  are  as  near 
as  possible  to  the  perceived  military  requirement  The  performance  of  these  protocols  is  being 
established  under  ideal  and  degraded  conditions  in  the  laboratory. 

Initial  work  has  concentrated  on  the  X.400  and  FT AM  standards.  A  protocol  stack,  using 
X.400  or  FT AM,  Transport  Service  Class  4  (TP4),  and  connectionless  network  service  (CLNS) 
over  X.25(1984)  has  been  selected.  These  were  selected  to  give  a  worst  case  scenario  for 
evaluating  the  protocol  standards.  Early  results  have  provided  an  upper  bound  tr  the  overheads 
that  may  be  experienced  under  ideal  conditions.  This  result  will  be  used  for  the  design  and  sizing 
of  messaging  networks.  Some  measurements  on  the  performance  of  FT AM  ova-  degraded  links 
have  also  been  obtained.  These  have  shown  how  a  more  "intelligent"  implementation  of  the  data 
link  protocol  could  provide  optimum  throughput  over  a  range  of  degraded  conditions.  [Ref.  Price 
1990] 

Defence  Fixed  Telecommunications  System  (DFTS).  MOD  Central  Defence 
staffs  are  establishing  a  Defence  Packet  Switched  Network  (DPSN).  This  project  is  a  major 
element  of  a  broader  Defence-wide  communications  infrastructure  covering  all  communications 
services:  the  DFTS.  Over  time,  the  present  MOD  and  Armed  Forces  communications  systems  will 
integrate  to  DFTS.  Profiles  that  have  Heen  recommended  for  the  DFTS  are  of  three  types:  end- 
system  services,  common  application  services,  and  basic  communications  services.  End-system 
services,  together  with  the  proposed  standards,  arc  electronic  trading  (based  on  EDI),  rcvisable 
document  exchange  (based  on  ODA),  general  file  transfer  (based  on  FT AM),  remote  terminal 
access  (based  on  VT),  inter-personal  messaging  (based  on  MMHS),  and  inter-organizational 
messaging  (also  based  on  MMHS).  Common  application  services  include  message  handling 
(MMHS),  Directory,  ACP  127  interworking  (MMHS),  shared  file  store  (FT AM),  and  shared 
database  (RDA  and  SQL).  The  basic  communications  service  profiles  are  T.31(M)  for  WAN 
access,  T/611  and  T/613  for  LAN  access,  R.131(M)  for  WAN-to-WAN  relay,  and  R/21  for  LAN- 
to-LAN  relay.  [Ref.  Bailey  1990] 

The  UK  MOD  has  a  commitment  to  provide  its  single-Service  strategic  communications 
needs  via  a  common  communication  network  (DFTS).  It  is  also  MOD  policy  that  such  provi  aon 
should,  to  the  greatest  extent  possible,  be  procured  from  the  civil  market  to  standards  recognized 
by  the  international  community.  Progress  in  implementing  the  DFTS  has  been  slow  as  the  priority 
of  each  of  the  Single  Services  has  been  to  deploy  their  own  systems,  leaving  convergence  to  DFTS 
until  a  later  date.  However,  one  subset  of  DFTS,  the  packet  switched  data  communications 
network  (DPSN),  was  identified  as  requiring  common  provision  to  satisfy  immediate  operational 
needs. 

Hie  DPSN  procurement  has  been  guided  by  the  DFTS  Architecture  and  Procurement 
Working  Grtiup  (DAPWG),  which  recommended  that  (1)  the  network  be  based  upon  the 
internationally  recognized  X.2S  standard  for  network  access;  and  (2)  potential  candidate  network 
systems  should  be  mature,  have  considerable  expansion  capability,  and  be  supported  by  a 
manufacturer  with  a  total  commitment  to  the  product  and  development  of  the  relevant  standards. 
The  procurement  has  been  distinguished  by  the  short  time  scale  between  statement  of  requirement 
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and  in-service  operation,  and  being  both  within  the  financial  provision  and  satisfying  the 
operational  requirement  For  the  future  some  significant  issues  have  to  be  developed  and  resolved, 
not  the  least  being  interworking  with  other  systems,  e.g.,  ISDN,  multilevel  security  and 
management  across  the  boundary  between  DPSN  and  end-user  systems.  [Ref.  Dibble  1990] 

WAVELL.  WAVELL  is  a  battlefield  ADP  system,  built  to  full  military  specifications 
including  TEMPEST  and  NBC.  It  is  designed  primarily  to  assist  G2/G3  staff  cells  in  headquarters 
at  corps,  division,  and  brigade  levels.  It  has  limited  G1/G4  functionality.  Full  deployment  to 
1  (Br)  Corps  was  completed  in  1987  and  the  latest  software  upgrade  (Version  S)  will  be  tested  at 
the  end  of  1991,  after  which  no  more  changes  to  the  existing  WAVELL  will  be  made.  [Ref. 
TSGCE  1991n] 

Quadrilateral  Interoperability  Field  System  (QIFS).  In  order  to  provide  the  ACE 
Rapid  Reaction  Corps  (ARRC)  with  international  interoperability  mechanisms,  the  United 
Kingdom,  as  framework  nation,  has  developed  and  produced  the  QIFS.  QIFS  is  the  UK 
contribution  to  the  QIP,  which  also  involves  the  national  army  tactical  CCISs  of  France  (SICF), 
Germany  (HEROS),  Italy  (STACCON),  and  the  United  States  (MCS).  Interoperability  is  achieved 
by  exchanging  ADatP-3  messages  through  X.400  message  handling  systems.  The  standards  used 
in  QIFS  can  be  effectively  divided  into  two  areas:  those  agreed  by  the  QIP  community  and  those 
chosen  for  use  on  the  national  side.  The  standards  are  as  follows: 

•  QIP  standards — modified  variant  of  X.400: 1984;  X.25:1984,  and  ADatP-3  message 
defined  in  STANAGs  5621  and  5624. 

•  QIFS  national  standards — two  commercial  X.400: 1988  products  conforming  to  UK 
GOSIP  4.0;  PTARMIGAN  X.25:1980;  and  the  IRIS/Message  Formatting  System 
(MFS)  application  package,  which  defines  and  validates  ADatP-3  messages. 
IRIS/MFS  is  also  used  in  the  AMH  project  within  ADSIA.  The  INGRES  6.4 
relational  database  management  system  is  used  to  archive  all  messages,  and  a  network 
management  package  has  been  developed  using  the  INGRES  Windows/4GL.  All 
workstations  use  the  Motif/X-Windows  graphical  user  interface  and  run  under  either 
SCO  UNIX  or  HP-UX. 

Interim  ACE  Rapid  Reaction  Corps  Information  System  (IARRCIS).  Project 
IARRCIS  is  a  system  for  the  ARRC  Headquarters  and  will  concentrate  on  providing  the  staff 
officer  with  the  ability  to  create  files  in  a  variety  of  COTS  packages  and  pass  these  files  over  a 
reliable  network  to  other  users.  The  standards  used  will  be  the  same  as  for  the  QIFS.  There  may 
be  two  operating  systems  within  IARRCIS:  where  possible  a  C2  E2  accredited  UNIX  operating 
system  will  be  used;  where  this  is  not  possible,  MS  DOS  may  be  used. 

WAVELL  Risk  Reduction  Exercise  (WRRE).  The  WRRE  was  an  attempt  to 
demonstrate  that  it  would  be  possible,  at  low  risk,  to  build  a  military  C2  system  from  COTS 
products.  The  project  was  commissioned  by  MOD(UK)  and  carried  out  by  the  Defence  Research 
Agency  (Fort  Halstead).  It  used  an  architecture  that  included  an  X.400: 1988  message  handling 
systems  and  X.25  packet-switched  network.  Some  useful  lessons  concerning  procurement  of 
systems  built  from  COTS  were  learned,  but  it  should  be  noted  that  the  system  built  was  not  a 
prototype  or  necessarily  an  architecture  that  will  be  adopted. 

UK  Army  CIS  Standards  Programme.135  The  UK  Army  has  initiated  a  program  of 
standardization  for  its  future  command,  control,  communications,  and  information  systems  (CIS) 


1 35  This  section  is  based  on  excerpts  from  [Fowler  1993]  and  [Sutherland  1993]. 
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aimed  at  achieving  and  integrating  CIS  by  2010.  CIS  covered  by  the  program  will  include  all 
systems  used  on  and  off  the  battlefield  to  support  the  preparation,  deployment,  and  operations  of 
land  forces.  An  initial  stage  in  the  standards  program,  defining  the  intercept  strategy  for  common 
standards  approach  to  CIS  procurement,  was  conducted  during  May  1991  to  January  1992. 
Remaining  stages  are  to  identify  and  specify  common  CIS  standards;  and  to  identify  and  specify 
‘‘environment-specific”  standards  for  operational  and  support/planning  systems  that  lie  outside 
common  standardization  areas.  This  program  is  an  outgrowth  of  several  information  system 
strategy  studies  begun  in  1988  (command,  logistics,  and  personnel),  which  were  combined  to 
form  a  coherent,  consistent  Army  strategy  and  Goal  Architecture. 

Three  CIS  infrastructures  were  designated  to  host  the  CIS  projects:  CASHfWAVELL, 
serving  Army  Headquarters  at  and  above  the  one-star  level  (CASH  will  service  fixed,  peace-time 
headquarters  and  provide  maximum  compatibility  with  Enhanced  WAVELL  for  battlefield  use); 
UNICOM,  serving  Army  units  below  the  one-star  level  in  barracks;  and  CHOTS,  serving  MOD 
Headquarters.  MOD  has  recently  decided  that  CASH  will  adopt  the  CHOTS  infrastructure.  Some 
standards  for  these  infrastructures  have  already  been  defined,  further  constraining  the  choice  of 
standards  for  die  CIS  program. 

At  a  minimum,  tire  requirement  for  interconnections  is  to  exchange  data,  leading  to  a 
demand  for  common  communication  standards;  common  data  definitions,  formatting,  and 
encoding;  common  formatting  of  documents  and  messages;  and  compatible  security  arrangements, 
both  procedural  and  electronic.  In  the  communications  area,  an  internetworking  service  is  needed 
across  all  networks,  both  fixed  and  tactical.  Requirements  for  the  “military  network  service” 
include  the  following,  based  on  UK  and  NATO  studies: 

•  Security  features  (peer  entity  authentication,  access  control,  connection  confidentiality, 
connection  integrity  without  recovery,  traffic  flow  confidentiality) 

•  Multihoming,  mobile  hosts,  and  multi-addressing  (broadcast  mode) 

•  Automatic  provision  for  precedence  (four  levels)  and  preemption 

•  Queueing  of  input  traffic  and  allocation  to  available  circuits  to  produce  defined  transit 
delays. 

The  primary  areas  where  standards  are  needed  are  data  management,  security 
arrangements,  data  communications,  and  office  automation.  The  program  will  seek  to  minimize 
die  number  of  different  environments  to  facilitate  portability  between  hardware  platforms;  to  save 
on  personnel  recruitment,  training,  and  hiring  of  specialist  staff;  and  save  money.  Environment- 
specific  standards  may  be  required  for  geographic  information  systems,  hardware  ruggedization, 
and  tactical  communications.  Standards  deficiencies  were  noted  in  the  following  areas: 

•  Geographical  information  systems  (GISs) 

•  Y*deo  conferencing 

•  Digital  image  transmission 

•  Voice  input  to  computers 

•  KBS/KBS  (knowledge-based  system)  applications 

•  CALS  support  for  integrated  logistic  systems  and  CIRFLS. 
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Table  72  identifies  standards  currently  identified  for  the  UK  Army  CIS  Program  by  the 
Army  CIS  Agency  (ACISA). 

UK  MOD  Technology  Demonstrator  Programme.  The  UK  MOD  initiated  in  1993 
a  security  and  integrity  Technology  Demonstrator  Programme  (TDP),  which  will  attempt  to 
develop  security  standards  with  wide  commercial  application  and  viability.  The  program  is  based 
on  bilateral  contracts  between  the  MOD  and  a  number  of  core  product  suppliers,  who  will 
contribute  team  members  to  an  Industrial  College.  The  College  will  develop  an  initial  draft 
standard  for  a  security  architecture  and  an  implementation  plan.  This  cooperative  effort  between 
industry,  government,  and  commercial  users  is  hoped  to  provide  breakthroughs  in  the 
implementation  of  information  technology  security  that  meets  end-user  needs.  A  principle 
challenge  will  be  to  ensure  interoperability  between  product  sets  of  participating  suppliers  and  gain 
acceptance  of  standards-making  bodies  such  as  POSIX.  [Ref.  Government  Computing  1993] 

Following  endorsement  of  the  scoping  study  recommendations  in  October  1992,  work  has 
been  initialed  to  set  up  die  Army  Communications  and  Information  System  Standards  Management 
Organization  (ACISSMO)  to  manage  the  Army’s  continuing  requirement  for  CIS  standards.  It  is 
expected  that  ACISSMO  will  be  operational  by  April  1994.  In  the  interim,  work  has  continued  to 
ensure  dial  die  standards  recommendations  continue  to  be  relevant  for  the  Army’s  requirements. 
Further  work  is  being  done  to  clarify  the  recommendations  for  human-computer  interface  and 
geographic  information  systems.  [Ref.  Liddell  1994] 

19.10  Australia 

Centralized  planning  by  Headquarters  Australian  Defence  Force  (HQADF)  has  resulted  in  a 
Defence  Communications  Corporate  Han  (DCCP)  [Ref.  DCCP  1991],  which  has  embraced  a 
move  towards  increased  adoption  of  global  civil  telecommunications  standards.  This  plan  includes 
die  following  recommendations: 

A  long-term  research  program.  Defence  Organization  Integrated  Communications 
(DORIC),  is  under  way  to  define  and  demonstrate  an  integrated  communications  architecture  for 
the  Australian  Defence  Organization  into  the  21st  Century.  DORIC  is  centered  around  providing  a 
global  backbone  for  C2I  traffic  and  takes  into  account  the  possibilities  of  transporting  large 
databases,  video  teleconferencing,  imagery,  sensor  data,  and  intelligence  traffic.  DORIC  seeks  to 
enable  current  and  future  traffic  types  to  share  common  access,  switching,  and  transmission  assets. 
DORIC  will  address  military  attributes  such  as  security,  survivability,  trustworthiness,  priority, 
and  preemption.  Among  techniques  being  examined  is  EVEREST,  which  enables  practical 
adaptive  radio  systems  by  rapidly,  passively,  and  accurately  estimating  the  probability  of  error  over 
non-Ganssian  radio  channels  in  an  unbiased  manner.  Experimental  ATM  switches  have  been 
developed. 
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Table  72.  UK  MOD  Draft  Standards  for  CIS  Systams 


OOMXMF 


Mamy 


Graphics 


Office  Automation 


OOP-TP 


OOP-DDB 


ODP-flDB 


Graphics 

Kernels 


Data  Store 


Intercept 

Standard 


ISO  10027 


ISO  8613 


ISO  7962 
ISO  9735 
STANAG5600 

Series 


ISO  9804 
ISO  9605 


COTS 


COTS 


ISO  8632 


COTS 


COTS 

Various  Stds 


IS0 10026 


ISO  9075 


ISO  9579 
ISO  8649 
ISO  8649 
ISO  8660 
ISO  9072 


Note  3 


ISO  9945 


ISO  7165 
ISO  1538 
ISO  1539 
IS0 1969 
ISO  6160 
DEFSTAN0646 


ISO  9075 
ISO  8652 
ISO  DP  8466 
COTS 


ISO  8632 
ISO  7942 
ISO  9592 
ISO  9593 


ISO  Various 


COTS 


Total 

Standard 


IS0 10027 


ISO  8613 


ISO  7982 
ISO  9735 
STANAG5500 

Series 


ISO  9804 
ISO  9605 


Not  Defined 


Not  Defined 
ISO  9836 
ISO  8632 


Not  Defined 
Not  Defined 


Not  Defined 
Not  Defined 


IS0 10026 


Not  Defined 


Not  Defined 


Not  Defined 


ISO  9945 


ISO  71 85 
IS0 1538 
IS0 1539 
IS0 1969 
ISO  6160 
DEFSTAN0646 


ISO  9075 

ISO  8652 

ISO  DP  8496 

»■-*  - ‘ 

mm  UmumU 


DIS9636 
ISO  8632 
ISO  7942 
ISO  9592 
ISO  9593 


ISO  Various 


Further 

Work 


Note  4 


LAN/WAN 

Inter¬ 

connection 


IS0 10030 
ISO  9542 
COTS 


Not  Defined 


GOSIP-T/X.25 


GOSIP-T 


IS0 10030 
ISO  9542 
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Tab!*  72.  (Confd) 


Title 

Intercept 

Standard 

Total 

Standard 

Applicability 

Further 

Work 

WAN 

GOSIP-T/X25 

SNA  Gateway 

GOSIP-T/X.25 

Army 

IBM 

F  S 

LAN 

GOSIP-T 
(Note  5) 

GOSIP-T 

Proj 

LAWWAN 

Inter¬ 

connection 

wsraswewe  • 

IS0 10030 

ISO  9542 

COTS 

IS0 10030 

ISO  9542 

Army 

Army 

BM 

F 

FTAM 

ENV  41204 

ISO  8571 

Army 

VT 

ISO  9040/41 

oars 

ISO  9040/41 

Army 

P«i 

F  S 

MHS 

IS0 10021  or 
STANAG4406 

IS0 10021 
STANAG4406 

Army 

Army 

F  S 

F  S 

JTM 

oars 

ISO  8831/3 

IBM 

Army 

F 

F 

DTAM 

GCITTT.430 

oars 

CCfTTT.430 

Army 

BM 

F 

F 

Characters 

Not  Defined 

n«-A  ra.n - 1 

MOV  LWfllN 

Army 

F  P 

N&A 

Not  Defined 

ISO  9594 

Army 

F 

- 1. 

NMWDrK 

Managsmant 

1809596 

ISO  9595 

DIS 10040 

DIS 10164 

ISO  9596 
1809595 

D)S  10040 

DIS  10164 

Army 

Army 

Army 

Army 

F  SS 

F  SS 

F  SS 

F  SS 

Security 

CESG 

CESG 

Army 

F  SS 

Key  for  AppfcabBlty: 

Army:  Applicable  army- wide 

Profc  to  nroiB  of  nroiscf 

IBM:  AppBcafals  to  the  A-Area  BM  environment 

Kay  for  Work: 

Fnanilliwnanf  fnr  Itinrtipfeatinw  w—H  iw  h«  rUHfiari 

MMa  jiJ  u|u4u4a  iMMlAmAMiltkia  llkA  aittiulMifl  MAArla  4a  ka  I|maaa4Lm4a#I 

im  vw>gs  o»  prDCMCV  urpisfnsniiny  vw  mnoMu  nssoi  «o  do  nvasugMo 
S:  Tha  standards  need  to  ba  jnvactigiited  further 

88:  rmarglnfl  atandarda  (Inciudkig  da  fado)  naad  to  ba  monbored 

Note  1:  Tha  (feat  atandard  rates  to  financial  data  snehangr,  the  aacond  to  BMFAGT,  and  tha  third 
to  operational  maaaaging,  probably  to  ba  NATO-wide  using  tha  established  ADatP-3 
standards. 

Note  2:  Sea  Rows  on  Third  QeneraBon  Languages  (OQiysQL;  SQL  la  a  racommandad  Army-wlda 
standard  that  is  known  to  ba  supported  by  tha  leacSng  relational  database  management 
system  (RDBMS)  products. 

Note  3:  Tha  battlefield  environ  merit  may  require  (notifications  to  tha  mechanical  design  of 
QWERTY  keyboards,  for  example,  to  permit  operation  by  gloved  hands,  and  there  may  ba 
a  continuing  requirement  for  specialized  peripherals  such  as  hand-held  date-entry 
kevoada  tracker  bale.  Baht  nans  ate. 

r«aj|m«ra|  is^nfi^ar  w^raei  rasas  se  bswsivi  wwrt 

Note  4:  ACISA  is  currently  investigating  the  implications  of  adopting  the  CHOTS  HQ  for  Amny- 
wideuse. 

Note  6:  Covers  profBaa  for  CSMA-CO  and  Token  Ring  (6602-3/8/6)  and  FDOi. 

Source:  AQ8A  (UddeN  1994], 
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19.11  United  States 

19.11.1  US  Defense  Standardization  Programs 

US  DTMP  Standards  Development13*  This  section  summarizes  standardization 
activities  being  conducted  in  die  US  DoD  related  to  data  communications  for  open  systems 
implementation.  The  coordinating  body  for  these  activity  is  the  Data  Communications  Protocol 
Standards  (DCPS)  Technical  Management  Panel  (DTMP).  The  work  of  each  of  the  working 
groups  of  die  DTMP  may  be  summarized  as  follows: 

•  WG1  on  Lower  Layers — thin  stacks  for  OSI,  multicasting:  transport  profile,  simplex 
profile,  Internet  profile,  and  wireless  LAN;  work  on  Enhanced  Communication 
Functions  and  Facilities  (ECFF);  work  on  National  Imagery  Transmission  Format 
(NITF)  addressing  full-duplex  and  half -duplex  (but  not  simplex)  capability  and  large- 
imagery  file  transfer;  protocols  for  USSPACECOM  and  liaison  with  the  Space 
Communications  Protocol  Standards  Technical  Working  Group  (SCPS-TWG),  a  joint 
effort  of  D6D  and  NASA;  Reliable  End-System  Transport  profile 

•  WG2  on  Upper  Layers — MHS  profile;  restricted  MMHS  profile;  FT  AM  profile; 
Internet  profiles  on  file  transfer,  remote  login,  and  domain  name  system;  SMTP; 
interoperability  testing;  gaining  national  and  international  acceptance  of  the  P772 
Military  Message  content  type  in  MMHS,  such  as  proposing  modifications  to  KjOSS 
and  US  GOSIP,  working  with  ANSI  and  NIST 

•  WG3  on  Security — security  labelling  (Common  Security  Label);  Message  Security 
Protocol  (MSP),  including  promulgating  MSP  to  the  international  level  through  NIST 
and  whether  NSA  will  release  key  management  information  required  for  common 
MSP  usage  at  the  international  level;  security  frameworks  and  Generic  Upper  Layer 
Security  (GULS);  Secure  Data  Network  System  (SDNS) 

•  WG4  on  Network  Management — Network  Management  for  DoD  Communications; 
SNMP;  managed  objects;  DoD  Network  Management  Information  Model  (MIM) 

•  WGS  on  Architecture — Technical  Reference  Model  (TRM)  project;  conceptual 
requirements  for  DoD;  identifying  holes  in  the  DTMP  standards  framework; 
harmonizing  DTMP  TRM,  DoD  TRM,  and  OSE/IA  model;  networking  section  of 
ITSG-OSE  (formerly  OSE/IA);  wireless  LAN  project  (with  WG1) 

•  WG6  on  Registration  [dissolved  in  1993  in  favor  of  the  GOSIP  Advisory  Group  on 
Registration  (GAG-R)] 

•  WG7  on  Testing — MIL-HDBK-1350  on  testing  with  separate  volumes  on  protocol 
validation  plan  and  conformance  and  interoperability  testing  (dan  (this  working  group 
may  be  dissolved  following  publication  of  these  two  volumes);  assisting  validation  of 
message  handling,  MSP,  and  reliable  end-system  transport  imagery 

•  liaison  and  related  activities 

Federal  Internetworking  Requirements  Panel  (FIRP) — appointed  by  NIST  at  the 
direction  of  the  Federal  Networking  Council  (FNC)  to  study  issues  and 
recommend  long-  and  short-term  actions  in  connection  with  the  standardization  of 
communications  protocols;  addressing  comparative  strengths  and  weaknesses  of 
the  OSI  and  Internet  protocol  suites;  ease  of  use,  economic  impacts,  and 
commitments  to  other  entities  such  as  NATO;  convergence  of  the  two  protocol 
suites;  possible  use  of  TCP/IP  as  a  prescribed  protocol  suite  in  US  GOSIP 
(Version  3  of  US  GOSIP  is  being  delayed  pending  recommendations  of  the 
FIRP) 


136  Based  on  the  following  sources:  (DTMP  1993a),  [DTMP  1993b],  [DTMP  1993c).  [DTMP  1993d),  mi 
(DTMP  1994a). 
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OIW:  Expansion  of  OIW  to  increase  focus  on  open  systems  environment  (OSE); 
new  special  interest  group  on  multimedia 

OSI  Implementation  Strategy  document— current  version  compares  TCP/IP  to 
OSI  and  recommends  a  dual-stack  instead  of  a  split-stack  approach;  three-phase 
strategy,  of  which  the  second  is  the  current  phase:  (1)  increasing  OSI  protocol 
experience  and  implementation  of  some  Application  Layer  gateways, 
(2)  activation  of  additional  OSI  services,  and  (3)  final  implementation,  requiring 
the  acquisition  of  fully  tested  and  certified  advanced  OSI  capabilities 
rrSG-OSE  (formerly  OSE/IA) — provides  consistent  open  systems  IT  standards 
acquisition  guidance;  examines  various  IT  standards  categories;  prescribes 
mandatory  standards  within  each  area;  and  provides  interim  solutions  and 
emerging  options  to  address  areas  with  standards  deficiencies. 

DoD  E-Mail  Strategy — Version  2  of  Message  Security  Protocol  (unclassified  and 
approved  for  public  release);  convergence  of  MSP  with  X.400 
JTSSG:  Telecommunications  Systems  Standards  (TCSS)  program,  FED-STD- 
1037B,  STANAG  responsibility;  Federal  Wireless  Users  Forum  (FWUF);  Tri- 
Service  Open  Systems  Architecture  Working  Group;  Defense  Standardization 
Program  (DSP)  Mission  Critical  Computer  Resources  (MCCR),  which  is 
establishing  an  opens  systems  architecture  for  embedded  weapon  systems; 
Imagery  Standards  Management  Committee  (1MSC) 

ITU-TS  OSI  Efficiency  Meeting 

Internet  Engineering  Task  Force  (IETF) — TCP/IP-OSI  migration  issue;  IP  Next 
Generation  Meeting;  working  groups  on  IP  over  Asynchronous  Transfer  Mode 
(ATM),  TCP/User  Datagram  Protocol  (UDP)  with  Big  Addresses  (TUBA), 
Internet  Protocol  Security  Protocol  (IPSEC),  and  Inter-Domain  Multicast  Routing 
(IDMR);  potential  problems  with  the  Network  Layer  Security  Protocol  (NLSP); 
11  functional  areas  in  IETF  with  working  groups  established  to  work  on  separate 
issues  in  each  area 

Defense  Information  Infrastructure  (DII)  and  US  National  Information 
Infrastructure  (Nil) 

Support  for  and  review  of  drafts  for  next  edition  of  WP  25. 

US  Space  Command  (USPACECOM)  Standardization.  The  Space 
Communications  Protocol  Standards  Technical  Working  Group  (SCPS-TWG),  a  joint  effort  of 
DoD  and  NASA,  is  an  effort  initiated  to  provide  open  systems  capabilities  for  the  North  American 
Air  Defense  (NORAD)  USPACECOM  Integrated  Command  and  Control  System  (NUICCS), 
which  is  the  C2  infrastructure  that  supports  the  commanders-in-chief  (CINCs)  of  NORAD  and 
USSPACECOM.  The  NUICCS  is  composed  of  over  200  major  elements,  command  centers, 
communications  networks,  and  data  processing  systems.  New  mandatory  terrestrial 
communications  protocols  have  been  defined  (N/SP-STD-1100B)  that  are  fully  US  GOSIP 
compliant  Additional  work  by  the  SCPS-TWG  is  focused  on  reducing  the  overhead  of  OSI 
protocols  to  make  them  more  usable  in  the  bandwidth-limited  space  environment  Other  standards 
work  includes  the  use  of  application-process-to-application-process  message-embedded  cyclic 
redundancy  check  (N/SP-STD- 1 500A);  standard  structure  for  formatted  messages  and  message 
sets  (N/SP-STD- 1700);  and  real/test/exercise  capabilities  standard  (N/SP-STD-1900).  [Ref. 
DTMP  1993a] 

Common  Data  Link  (CDL)  Program.  DISA/DSPO  has  initiated  the  CDL  program  to 
ensure  interoperability  at  the  data  link  operations  level  and  to  provide  commonalty  to  reduce 
development  and  support  cost  DSPO  has  developed  an  IC3  architecture  whose  goal  is  global  C3 
via  selected  satellites.  Studies  are  being  conducted  or  planned  on  architecture,  partitioning, 
commercial  standards,  waveforms,  data  formats,  protocols,  networks,  interoperability  issues,  and 
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acquisition  techniques.  Standards  anticipated  for  CDL  include  moderate-rate  LAN  interface  in 
1995,  high-rate  bus  interface  in  1996,  and  high-rate  LAN  interface  in  1998.  [Ref.  DTMP  1993a] 

ITSDN  Program  and  Standards  for  US  DoD.137  The  US  DoD  has  developed, 
coordinated,  and  validated  a  program  plan  [Ref.  DISA  1992]  for  the  Integrated  Tactical  Strategic 
Digital  Network  (ITSDN)  to  focus  DoD’s  efforts  to  attain  tactical-to-strategic  and  tactical-to- tactical 
data  communications  interoperability.  This  plan  is  an  outgrowth  of  a  1989  demonstration  of  the 
use  of  packet  switching  technology  and  end-to-end  encryption  (E3)  technology  in  the  military 
tactical  system  environment  That  demonstration,  using  BLACKER,  showed  that  tactical  data 
networks  could  be  connected  to,  and  made  to  interoperate  with,  the  strategic  Defense  Data  Network 
[DDN,  now  the  Defense  Information  System  Network  (DISN)]. 

The  ITSDN  program  has  been  charged  with  identifying  solutions  for  interconnectivity  and 
interoperability  between  data  networks  supporting  strategic,  CINC,  JTF,  and  tactical  data  systems, 
providing  for  the  following:  ( 

•  Tactical  access  to  national  and  strategic  information  resources 

•  Multi-level  secure  data  communications 

•  Use  of  standard  protocols  and  interfaces 

•  Improved  bandwidth  utilization 

•  Emphasis  on  the  use  of  commercial  and  non-developmental  solutions 

•  Architecture  based  on  compatibility  with  Service  tactical  data  network  plans,  with 
minimal  equipment  introduced  in  theater  to  support  ITSDN 

•  Basis  for  tactical  evolution  to  US  GOSIP. 

ITSDN  will  be  based  on  the  use  of  the  DoD  standard  protocol  suite,  with  an  undefined 
migration  to  GOSIP  protocols.  A  mixed  stack  X.400  over  TCP/IP  is  expected.  Interconnection 
and  two-way  data  exchange  across  system  boundaries  at  multiple  security  levels  will  be 
accomplished  according  to  a  jointly  defined  and  validated  security  architecture  (yet  to  be 
developed).  However,  the  systems  to  be  interconnected  have  very  different  security  architectures 
and  include  schemes  for  physical  separation  of  traffic  at  different  security  levels,  cryptographic 
separation  of  traffic  at  different  security  levels,  system-high  security  protection,  and  human-in-the- 
loop  security  mechanisms.  Available  mechanisms  include  E3,  label-based  mechanisms,  guard 
devices,  and  application  layer  security  protocols,  which  will  need  to  be  implemented  in  an 
evolutionary  fashion  as  the  technology  to  support  the  mechanisms  matures.  The  following  are 
examples  of  networks  to  be  interconnected  using  ITSDN: 

•  DISN,  which  is  composed  of  four  separate  worldwide  packet  switched  networks: 
MDLNET  (carrying  unclassified  and  sensitive  traffic);  DSNET1  (secret),  DSNET2  (top 
secret),  and  DSNET3  [top  secret/special  compartmented  information  (SCI)].  DISN  is 
evolving  to  include  provision  of  high-speed  data  switching  and  routing  using  BP 
routers,  providing  users  with  connectivity  options  such  as  X.25  networks  and  high¬ 
speed  IP  networks.  Strategic  DISN  subscriber  systems  will  be  migrating  to  GOSBP 
protocols,  and  the  DISN  will  provide  network  support  for  GOSIP  users. 

•  Tactical  switching  systems  such  as  Mobile  Subscriber  Equipment  (MSE),  Tactical 
Secure  Data  Communications  (TASDAC),  and  Tactical  Communications  Distribution 
Node  (TCDN). 

•  Information  exchange  links  in  Copernicus. 


137  This  section  is  based  on  excerpts  from  [Penmngton  1993]. 
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Secure  Tactical  Data  Network  (STDN)  Demonstrations.138  ITSDN  program 
participants  recognized  early  that  the  integration  of  the  strategic  and  tactical  communications 
security  architectures  would  pose  particularly  difficult  problems  from  both  a  policy  and 
technological  standpoint  The  strategic  network  security  architecture  was  developed  as  part  of  the 
DISN-Near  Term  (DISN-NT)  program  largely  without  regard  to  tactical  considerations.  Since  the 
initial  tactical  packet  networking  capabilities  were  developed  by  the  Services  to  satisfy  Service- 
specific  requirements,  separate  approaches  to  data  security  began  to  evolve  within  the  Services. 
Thus,  the  ITSDN  program  plan  identified  the  need  to  unify  these  efforts  through  an  integrated 
tactical  security  architecture  that  would  be  compatible  with  the  DISN-NT  strategic  security 
architecture. 

Early  data  communications  experiments  were  conducted  by  the  US  Army  at  the  Army 
Signal  Center  in  Fort  Gordon,  Georgia.  It  soon  became  apparent  that  these  experiments  had  the 
potential  to  become  a  basis  for  a  joint  test  bed  activity  in  which  many  of  the  more  complex  joint 
networking  problems  might  also  be  addressed.  Thus,  the  operational  impetus  of  the  Army  internal 
data  networking  requirements,  the  ITSDN  joint  requirement,  and  the  emerging  goals  of  the  C4I  for 
the  Warrior  (C4IFTW)  Joint  Staff  initiative  became  die  basis  for  a  series  of  joint  Secure  Tactical 
Data  Network  (STDN)  demonstrations.  STDNs  would  be  led  by  the  Services  with 
DISA/JIEO/JITC  support  and  would  serve  as  a  means  to  demonstrate  and  assess  joint  C4I  data 
systems  interoperability  and  to  identify  both  procedural  and  technical  solutions  to  current 
interoperability  problems.  Additionally,  the  demonstrations  would  allow  commercial  vendors  to 
show  how  their  products  potentially  could  satisfy  C4IFTW  needs. 

The  first  three  STDN  demonstrations  (STDN-1  through  STDN-3)  were  conducted  at  the 
Army  Signal  Center,  Fort  Gordon.  Georgia.  The  Army  acted  as  host  in  each  case.  Initially,  the 
focus  was  only  on  communications  and  data  network  connectivity;  however,  STDN-3  was 
broadened  to  include  data  systems  applications  interoperability  among  the  components  of  a  joint 
task  force  (JTF). 

STDN-4,  the  fourth  in  the  series  of  STDN  demonstrations,  was  hosted  by  the  Navy  and 
focused  on  C4I  support  for  a  maritime  joint  task  force  operating  in  the  Pacific  theater.  Actively 
supported  by  USCINCPAC,  this  latest  STDN  included  a  broad  range  of  C4I  technology 
demonstrations  and  undertook  serious  efforts  to  implement  advanced  C4IFTW  operational 
concepts  using  those  technologies. 

The  STDN-4  demonstration  was  conducted  during  August  to  September  1993.  Of  special 
significance  was  the  design  and  installation  of  the  “Wahiawa  Super  Gateway”  in  Hawaii.  This 
gateway  was  the  centerpiece  of  the  architecture  that  provided  data  communications  connectivity 
between  shore-based  command  centers  (i.e.,  USCINCPAC  and  its  components)  and  a  deployed 
JTF  and  its  components  via  SHF  SATCOM.  STDN-4  broke  new  ground  in  achieving  wide  area 
communications  connectivity  and  also  in  giving  C4IFTW  program  visibility  to  the  warriors 
themselves.  It  was  the  first  of  the  demonstrations  to  involve  a  CINC  and  the  first  to  use  a  CINC’s 
force  as  the  JTF.  The  fact  that  the  JTF  was  afloat  added  to  the  importance  of  the  demonstration. 
Finally,  there  was  significant  participation  from  all  four  Services. 


138  Hie  KCtkn  U  based  ot>  [STDN-4 1993a],  STDN-4 1993b],  and  [Walsh  1994}. 
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The  following  general  results  of  STDN-4  indicate  the  breadth  of  capabilities  that  were 
actually  shown  to  work  and  the  expanding  level  of  expertise  in  the  joint  C4IFTW  community  with 
regard  to  data  networking  technology: 

•  A  wide-area  joint  network  of  networks  was  established  and  data  was  exchanged 
among  a  variety  of  users  operating  a  variety  of  systems  in  a  variety  of  environments. 

•  A  C4I  system  that  supported  the  PACOM  Two-Tier  C2  concept  was  demonstrated. 

•  A  C4I  system  that  provided  a  maritime  JTF  advanced  information  exchange  capability 
over  extended  distances  was  demonstrated. 

•  Warrior  information  pulls  were  achieved,  most  notably  in  intelligence. 

•  Useful  advanced  C2  technologies,  such  as  distributive  collaborative  planning  tools, 
were  demonstrated. 

The  original  purpose  of  the  STDN  series  of  demonstrations  was  to  advance  the  technical 
and  operational  understanding  of  the  participants  regarding  the  interconnection  of  tactical  packet 
communications  networks  with  strategic  long-haul  packet  networks.  The  principal  means  to 
achieve  this  purpose  has  been  the  actual  assemblage,  test,  and  operation  of  equipment  strings  in  the 
field  using  currently  fielded  or  readily  available  hardware  and  software.  This  approach  to  what  is 
becoming  an  increasingly  complex  problem  allows  Service  personnel  to  get  smart  quickly  on  the 
capabilities  of  present  day  technology,  to  experiment  with  alternative  interconnection  means,  and  to 
understand  early  on  what  inter-networking  solutions  will  and  will  not  work  in  a  tactical 
environment  The  strong  emphasis  on  learning  through  doing  has  been  the  trademark  of  STDN 
demonstrations. 

More  recently,  particularly  in  STDN-4,  the  scope  of  activities  has  increased  beyond 
communications  networking.  The  STDN  agenda  now  includes  a  full  range  of  C4I  technology 
demonstrations  and  serious  efforts  to  implement  advanced  C4IFTW  operational  concepts  using  that 
technology.  While  there  is  obviously  a  strong  desire  in  the  C4I  community  to  quickly  implement 
new  capabilities  that  warriors  can  relate  to,  there  is  also  a  real  danger  in  trying  to  mix  too  much 
new  technology  with  new  concepts  too  fast,  especially  in  a  relatively  unstructured  demonstration 
environment  The  challenge  of  managing  this  complex  activity  under  the  heretofore  ad  hoc  STDN 
program  appears  to  be  too  great  A  new  demonstration  program  construct  is  needed. 

Joint  Warrior  Interoperability  Demonstration  (JWID).  The  name  “STDN”  was 
originally  conceived  by  the  technical  community  to  describe  a  relatively  narrowly  focused  technical 
activity.  That  name  no  longer  accurately  describes  the  broader  command  and  control  activity  that 
has  evolved  and  it  certainly  does  not  encourage  warrior  involvement  or  interest;  the  new  activity 
name  is  Joint  Warrior  Interoperability  Demonstration  (JWID).  The  next  JWID  is  planned  for 
1994.  [Ref.  Walsh  1994] 

19.11.2  US  DoD  Transition  to  GOSIP139 

The  US  DoD  intends  to  adopt  OSI  protocols  as  a  full  co-standard  with  DoD  protocols, 
specifically  for  message  handling  and  file  transfer  (MIL- STDs  1777, 1778, 1780,  and  1781).  OSI 
protocols  are  expected  to  "become  the  sole  mandatory  interoperable  protocol  suite."  [Ref. 
ASDC31 1987]  The  Defense  Communications  Agency  (DC A)  [now  the  Defense  Information 
Systems  Agency  (DIS A)]  has  been  named  as  the  DoD  Executive  Agent  for  Data  Communications 
Protocol  Standards,  and  in  June  1988  this  agency  promulgated  an  OSI  implementation  strategy. 


139  This  section  it  based  on  excerpts  from  [Bryan  1993]. 
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[Ref.  DCA  1988]  The  Services  and  Agencies  have  developed  transition  plans  to  comply  with  this 
strategy. 

Although  mandated  for  tactical,  strategic,  and  mission  support  information  systems,  DoD’s 
OSI  migration  efforts  have  been  focused  primarily  on  strategic  and  mission  support  systems.  DoD 
established  the  Defense  Message  System  (DMS)  program  to  migrate  from  the  existing  AUTODIN 
messaging  system  to  X.400-based  implementations  within  strategic  and  mission  support  systems. 
Concurrently,  the  DoD,  through  the  DMS  Program  Office,  has  participated  in  the  allied  effort  to 
develop  ACP-123  in  die  strategic  world  (to  replace  the  commonly  used  ACP-127  messages). 
Today’s  C3I  systems  rely  heavily  on  the  transferring  of  messages  around  the  tactical  environment 
and  between  die  tactical  and  strategic  environment 

Although  one  of  the  most  extensive  and  pervasive  OSI-based  programs,  DMS  is  not  the 
only  OSI  user  within  DoD.  The  Defense  Information  System  Network  (DISN)  is  also  migrating  to 
OSI  support  The  DISN  routers  currendy  support  both  the  Internet  Protocol  (IP)  and  the  OSI- 
based  connectionless-mode  network  protocol  (CLNP).  Additionally,  an  SMTP-to-X.400 
application  gateways  exists  to  connect  TCP/IP-based  users  to  OSI-based  users.  DoD  recently 
approved  a  DoD  standardized  profile  (DSP)  based  on  the  X.400  ISP  and  the  NATO  standardized 
profile  (NSP)  for  military  messages,  as  DoD  MIL-STD-2045-17501.  DSPs  for  specific  X.400 
content  types  are  also  being  developed. 

Rapidly  deployable  forces  require  joint  (and  combined)  connectivity  from  military 
commanders  at  the  level  of  CINCs  and  Joint  Task  Forces  (JIT's)  and  military  staff  at  the  level  of 
the  US  DoD  Joint  Staff.  Technology  allows  national  intelligence  assets  to  distribute  products 
directly  to  battlefield  commanders.  However,  many  people  remain  skeptical  about  the  ability  of 
OSI-based  protocols  and  products  to  operate  in  the  noisy,  bandwidth-limited,  closed  environment 
of  die  tactical  user.  Specific  concerns  include  the  following: 

•  Amount  of  achievable  information  throughput  given  the  overhead  normally  associated 
with  OSI  protocols  and  the  narrow  bandwidths  associated  with  tactical  circuits 

•  Ability  to  operate  in  a  simplex  mode  to  support  emission  control  requirements 

•  Lack  of  security  services  to  ensure  data  confidentiality,  data  integrity,  and  non¬ 
repudiation  of  sender  and  receiver 

•  Ability  to  operate  near-real-time  networks 

•  Ability  to  internetwork  with  existing  tactical  systems. 

19.11.3  US  Corporate  Information  Management 

The  US  DoD  has  initiated  a  major  effort  to  transition  the  DoD's  present  information 
systems  and  associated  information  technology  resources  to  a  communications  and  computing 
infrastructure  based  on  the  principles  of  open  systems  architecture  and  systems  transparency.  The 
breadth  of  this  work  is  for  DoD- wide  corporate  information  management  (CIM)  and  includes  in  its 
scope  both  tactical  and  strategic  CCISs.  A  summary  of  the  CIM  assessment  of  the  standards 
availability  is  given  in  Table  73.  The  column  on  standards  status  indicates  whether  adequate 
standards  are  now  or  in  the  future  available  for  each  service  and  if  not,  whether  there  is  a  gap 
(some  but  not  sufficient  standards)  or  a  void  (no  standards).  The  table  further  shows  the  dates  at 
which  US  federal  standards  (FlPSs)  are  expected. 
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Table  73.  US  DoD  (CIM)  Assessment  of  Standards  Availability 


TIMEFRAME  FOR  ST  AMO  ARDS  AVAILABIUTY 


t  OCT MM  I  1 0CT MM 


My:  •  Inotudsd  In  Ssptomter  1992  DoOPioMa  of  Standard*. 

Sourer  Ttehnkal  H»lm sno»  UoM  forlnformtton  Umwgmrmnt,  Vftion  1 3,  Coordnrton  Draft,  CsnMr  ter  IntonraMon 

Management,  CXSA,  30  September  1082,  UNCLASSIFIED. 
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Table  73.  (Continued) 


i  oct  ttw 


PknmdRPSPubfOaci 
Doeumrt  AioMmU^ 
Oeoa  OacMiranl 
MMOhmOi  FomasOeoa 


1 0CT  IMS  I  1 0CT  MM  I  1 0CT  IMS 


ooMoamoa 


HPS  Pub  152  (SQM_) 


HPS  Pub  12B  (COM) 


RPSPtf>150(Typ«1) 

PkmdRPSne 

(Typ*«) 


PhmdHP8Pub(MM  Draft  HPS 
^ - *  «  ^  ... - 

(flpnc  tNcranoi 

SpacBcMoMGES) 


8hnM(ShnMtoto 

EaMigiOflMal 


HPS  161  EMwX 
SrattMl 


HPS  PU)  120-1  (OKS) 


HPSPUb1S3(PHK3S) 


Kay:  •  Induuadln  Saplarnbar  1992DoO  ProWaotStarxlafdt- 

Sotjroa:  Technical  Hafcranoa  UoM  lor  MoomMon  Uantgmmnt,  Varakin  1 .3,  Coocdnabon  Draft.  Canty  tof  Information 

Managamant,  CXSA,  so  Oaptamtoar  1992.  UNCLASSIRED. 
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Tab  I*  73.  (Continuad) 


Kay;  •  InoluM  in  8^>lan^  1992  OoO  PioNa  o(  Slmlw*. 

8outm:  imxwwom  rwimwnct  moam  wr  wwommoon  mrnmQmfmfw,  Vernon  i  ^  uooravmon  uvwt,  mnest  iNomMon 

ManaganMnC  DiSA,  X  SapUmbar  1992,  UNCLA83IFIED. 
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19.11.4  DoD-Wide  and  Multi-Service  Architectures  and  Environments 

DoD  Integrated  Communications  Architecture.  The  Defense  Information  Systems 
Agency  (DISA)  and  the  military  Departments  are  formulating  information  and  security  architectures 
for  an  Integrated  Communications  Architecture  (ICA),  concerned  with  platform,  base-level,  and 
long-haul  communications.  These  architectures  are  expected  to  be  founded  on  local  ISDN 
switches  and  high-speed  LANs;  the  long-haul  networks  will  also  provide  ISDN  service.  In 
security,  new  technology  for  end-to-end  and  multi-level  security  devices  is  being  exploited.  [Ref. 
COPERNICUS  1991] 

Global  Command  and  Control  System  (GCCS)  Common  Operating 
Environment  (COE).14*  In  1993,  the  US  Joint  Staff  began  work  on  the  GCCS  with  two 
objectives:  replacement  of  the  Worldwide  Military  Command  and  Control  System  (WWMCCS) 
and  implementation  of  the  C4I  For  the  Warrior  concept  GCCS  is  planned  to  improve  the  joint 
warfighter’s  ability  to  manage  and  execute  humanitarian,  crisis,  and  contingency  operations  and 
provide  a  means  for  integration  of  the  Service  C4I  systems.  It  covers  the  spectrum  of  conflicts 
from  routine  peacetime  operations  to  non-nuclear  strategic  war.  The  concept  builds  upon  lessons 
learned  from  previous  conflicts,  operational  requirements,  the  effects  of  rapidly  changing 
technology,  and  the  direction  of  a  changing  national  security  strategy.  GCCS  will  become  the 
single  C4I  system  to  support  the  war  fighter,  whether  from  a  fox  hole  or  from  a  command  post 
The  GCCS  will  provide  a  single  view  of  the  military  C4I  for  the  joint  war  fighter.  The  view  will 
be  through  a  widely  distributed,  user  driven  network  to  which  the  war  fighter  “plugs  in.” 

In  the  past  grand  design  acquisition  strategies  often  failed  in  the  command  and  control 
(C2)  arena.  Large-scale  acquisitions  typically  take  years  to  scope  and  award.  Technology 
insertion  is  difficult  to  accomplish,  failing  to  take  advantage  of  technical  advances  and  price 
reductions.  The  GCCS  programs  break  with  this  model  of  development  They  plan  to  pursue  an 
evolutionary  migration  strategy  drat: 

•  Keeps  the  war  fighter  involved  at  all  levels 

•  Allows  the  war  fighter  to  retrieve,  manipulate,  share,  and  view  database  information  as 
needs  change 

•  Provides  a  unifying  architecture  that  provides  a  path  for  migration 

•  Builds  an  open  infrastructure  flexible  enough  to  easily  accommodate  future 
requirements 

•  Relies  upon  the  services  as  GCCS  components,  data  sources,  and  information  sources 

•  Provides  the  vehicle  for  technology  insertion. 

As  stated  in  the  Technical  Architecture  for  Information  Management  (TAFIM)  [Ref. 
TAFIM 1993,  Volume  3],  the  following  guidelines  apply  to  the  design  of  the  GCCS  COE: 

•  An  architecture  is  a  set  of  components  and  a  specification  of  how  these  components  are 
connected  to  meet  the  overall  requirements  of  an  information  system. 

•  The  components  of  an  architecture  provide  implementations  of  the  reference  model 
services  relevant  to  a  specific  system. 

•  An  architecture  will  contain  components  to  implement  only  those  reference  model 
services  that  it  requires. 


140  Based  on  GCCS  Common  Operating  Environment  [DISA  1994]. 
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•  Components  may  implement  one,  mote  than  one,  or  only  part  of  a  service  identified  in 
the  reference  model 

•  The  components  should  conform  to  the  profile  standards  that  are  relevant  to  the 
services  they  do  implement 

The  following  are  assumptions  related  to  the  GCCS  COE: 

•  The  COE  is  to  migrate  to  eventual  compliance  with  the  TAFIM,  Volume  3  and  die 
technical  reference  model  (TRM)  contained  in  Volume  2  of  the  TAFIM. 

•  Non-developmental  items  (NDIs),  including  both  commercial  off-the-shelf  (COTS) 
and  government  off-the-shelf  (GOTS),  are  the  preferred  implementation  approach. 

Standards  and  products  being  considered  for  the  near-term  version  of  GCCS  COE  are  shown  in 
Figure  39. 

The  GCCS  mission  area  applications  reside  at  the  top  of  the  DoD  Technical  Reference 
Model  Although  lower  layers  often  provide  services  that  are  useful  in  themselves,  the  principal 
purpose  of  die  lower  layers  is  to  support  the  mission  area  applications. 

The  GCCS  mission  area  applications  will  tend  to  be  custom  developed  and  targeted  to  a 
specific  function  or  user  community.  Mission  area  applications  can  build  upon  die  services  offered 
by  other  mission  area  applications,  support  applications  and  platform  services,  and  exchange  and 
make  use  of  information  in  other  mission  area  applications.  However,  mission  area  applications 
that  offer  shared  functions  to  be  used  by  a  variety  of  other  applications  can  be  considered  for 
inclusion  as  a  support  application. 

The  GCCS  mission  area  applications  can  be  one  or  a  combination  of  the  following: 

•  Candidate  applications  developed  by  die  Services;  Le.,  GOTS 

•  Candidate  applications  developed  by  the  Services,  which  are  modified  for  use  in  die 
GCCS 

•  Applications  custom  developed  for  the  GCCS 

•  COTS. 

The  preliminary  definition  of  the  GCCS  Block  1  is  the  following: 

•  Technical  Insertion  Program  (TIP)  [which  includes  Joint  Flow  and  Analysis  System 
for  Transportation  (JF AST),  Logistics  Sustainment  Analysis  and  Feasibility  Estimator 
(LOGSAFE),  Force  Augmentation  Planning  and  Execution  System  (FAPES),  and 
Dynamic  Analysis  and  Replanning  Tool  (DART)] 

•  Unified  Build  (UByOcean  Surveillance  System  (OSS) 

•  GCCS  Status  of  Resources  and  Training  Systems  (GSORTS) 

•  Contingency  Tactical  Air  Control  System  (TACS)  Automated  Planning  System 
(CTAPS)  module  for  Air  Tasking  Order  (ATO) 

•  USCINCEUR  Command  Center  System  (UCCS). 

GCCS  support  applications  can  provide  services  that  are  useful  without  need  for  a  mission 
area  application.  However,  the  support  applications  are  intended  to  be  building  Modes  for  the 
mission  area  applications.  According  to  the  TAFIM,  there  are  two  types  of  support  applications: 
programs  and  reusable  software  components.  The  programs  can  be  loaded  and  executed.  These 
programs  offer  a  service  to  other  support  applications  and  to  mission  area  applications.  The 
reusable  software  components  cannot  be  loaded  and  executed  themselves.  These  components  are 
incorporated  into  mission  area  and  support  applications.  Both  types  of  support  applications 
provide  common  functions  available  through  documented  interfaces. 
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Figure  99.  Near-Term  QCCS  COE 
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The  GCCS  support  applications  that  are  executable  include  COTS  and  GOTS  and  will  be 
shared  by  one  or  more  mission  area  or  support  applications.  Examples  of  common  COTS  support 
applications  are  word  processing,  transaction  processing,  screen  generation.  E-mail,  and 
spreadsheets.  Examples  of  GOTS  support  applications  are  audit  trail,  queue  manager,  and  alert 
manager.  The  support  applications  that  are  reusable  software  components  are  primarily  GOTS, 
although  there  is  no  technical  reason  preventing  use  of  reusable  COTS  components. 

Multi-Service  Common  Operating  Environment.  The  US  Army,  Navy,  Marine 
Corps,  and  Air  Force  agreed  in  1991  on  a  Common  Operating  Environment  (COE)  based,  in  part, 
on  US  GOSIP  and  the  NIST  APP/OSE.141  The  goal  of  the  COE  is  to  reach  consensus  among  die 
Services  as  a  means  of  promoting  interoperability,  portability  of  applications,  and  die  sharing  of 
ideas,  software,  and  data  products.  The  COE  addresses,  in  part,  the  growing  interdependence 
among  federal  organizations;  critical  need  for  common  architectures,  communications  networks, 
and  databases;  excessive  dependence  on  single  vendors;  and  underdeveloped  interoperability  of 
products  and  portability  of  people,  data,  and  applications.  Anticipated  benefits  are  improved 
efficiency  of  Service  systems  in  supporting  deployed  commanders,  reduced  costs  by  cutting 
development  and  fielding  time,  reduced  porting  effort,  improved  interoperability  between  systems, 
reduced  training  time,  reduced  duplication  of  effort  between  Services,  improved  system 
capabilities,  and  reduced  maintenance  efforts. 

The  COE  is  a  suite  of  standards  agreed  to  by  a  consensus  of  participants.  The  standards 
will  be  commercial  standards  where  possible  to  further  reduce  the  cost  of  developing  software. 
The  elements  of  the  environment  to  be  addressed,  eventually,  by  the  COE  standards  include  the 
following: 

•  Open  system  hardware  architecture 

•  Data  architecture 

•  Software  documentation 

•  LAN/BUS  interfaces 

•  Programming  language 

•  Operating  system 

•  Human-machine  interface 

•  Graphics  interface 

•  Map  and  overlay  display 

•  Real-time  track  database  management  services 

•  Encyclopedic  database  management  services 

•  Security  services. 

The  COE  Working  Group  has  agreed  to  commonality  in  the  following  areas:  POSIX 
compliance  (FIPS- 151);  Ada;  Ada-to-C  bindings  for  a  relational  database  management  system 
(DBMS),  X-Windows,  and  UNIX;  X- Windows  1 1.2  migrating  to  PEX;  Motif  as  the  graphic  user 
interface  (GUI);  SQL  and  its  evolutions;  and  TCP/IP  evolving  to  GOSIP  for  network  services. 
The  Services  are  now  actively  seeking  a  description  of  common  requirements  for  system 
architectures  and  system  specifications.  They  are  seeking  agreements  on  recommendations  for  a 
common  style  guide,  standard  interprocess  communications,  standard  map  data,  standard  graphic 


141  The  Air  Force,  Coast  Guard,  Defense  Intelligence  Agency,  Defense  Mapping  Agency,  JIBO,  and  tee  Joint 
Staff  are  ail  represented  in  COE  discussions. 
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user  interface,  standard  relational  DBMS-to-SQL  interface,  and  a  standard  map  display.  Table  74 
identifieg  die  services  for  the  COE  and  (in  the  second  column)  example  standards  (the  latter  are 
taken  from  die  Navy's  implementation).  [Ref.  COE  1991] 


Tabta  74.  US  Mutti-S«rvtc«  Common  Operating  Environment 


EXAMPLE  tTANOAROS 

System  Support 

Operating  systems 

Communications  interface  It  protocols 
wsKiueNng  inumanmacrsns  snsnaosj 

Systems  sdministvation 

System  msnagsmsnt 

System  security 

BUS  architecture 

UNIX-POSJX  compliant 

Q06IP,  TCP/IP,  SAFENET,  CSS 

X-Wlndow*  H  (Rato—  4) 

Diagnostic* 
cans.  CMP,  SNMP 

COMPUSEC  Oranga  Book,  SONS 

VME,  RJTUREBUSf 

Motif 

SQL  Ratotional  DBMS 

BTR 

Ada,  C,  Ada  bfmflnga 

Charts 

C2  Communications  Applcatione 

External  communications 

Message  prooeesing 

rniTelainn 

QLOSIXSs,  TAOfXSa,  Physical  nsta 

US  Msasaga  Tax!  Formats,  OTH-G, 

TAOXa  A  A  B,  Bk-oriaMsd  maaaagaa 

Attrfcutsa,  BJNT,  Probabtiiatic,  Acoustic 

Track,  CEP/OM 

Some*:  Fbtt Communkmtbm  in  thm  Copmkm  ArchlHclun.  final  Pratt.  20  June  1901,  UNCLASSIFIED. 


The  top-level  architecture  model  will  be  the  DoD  Technical  Reference  Model  (see 
Section  13  above),  and  a  combination  of  the  style  guides  for  die  DoD  Intelligence  Information 
Systems  (DODDS)  will  be  considered  as  the  DoD  human  computer  interface  style  guide.  The 
SQL- Ada  Module  Description  Language  (SAMeDL)  has  been  recommended  for  DBMS-SQL 
interface  (and  is  used  for  US  Marine  Corps  Common  Application  Support  Software  inter-module 
communication). 

SPACECOM  Assured  Mission  Support  Space  Architecture  (AMSSA).  Space 
Command  (SPACECOM)  has  developed  die  AMSSA  to  consolidate  several  architectures  and 
expend  them  to  all  elements  of  air-land-sea  forces.  The  goal  is  to  integrate  the  use  of  space-based 
satellites  with  the  communications  requirements  of  the  operational  forces.  The  AMSSA  seeks  to 
apply  "architectural-level"  interoperability  standards  across  communications;  navigation; 
environmental  monitoring;  intelligence;  surveillance;  mapping,  charting,  and  geodesy  (MCG); 
launch;  C2;  satellite  control;  and  logistics  functional  areas  in  support  of  die  tactical  user.  The 

architecture  seeks  standards  in  the  following  six  service  areas  with  die  associated  functions  and 

•  ■  .• _ 

•  Communications:  switching,  frequency,  data  rate,  wave  form 

•  Navigation:  geolocation,  timing,  velocity 

•  Launch:  nux-md-match  flexibility  and  intercompatibility 

•  Integrated  satellite  control  services  (ISCS):  satellite  control,  mission  data  processing, 
protected  links 

•  Integrated  logistics  support  (ILS):  supportable,  maintainable,  operable 

•  Command  and  control*  unity  of  command,  survivaUe. 
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Standards  are  to  be  open,  modular,  and  backward  compatible  without  dictating  particular 
engineering  solutions.  [Ref.  SPACECOM  1991] 


Defense- Wide  Common  Security  Architecture.  One  of  the  tasks  in  the  Defense- 
Wide  Information  Systems  Security  Program  (DISSP),  which  is  being  conducted  by  DISA  and  the 
National  Security  Agency,  is  the  development  of  a  Defense-Wide  Common  Security  Architecture. 
This  architecture  will  include  information  systems  security  standards  and  protocols,  uniform 
security  accreditation  procedures,  security  technology,  and  a  transition  plan.  The  architecture's 
scope  includes:  guidelines  for  system  design,  applicability  to  many  information  systems; 
addressing  systems  in  detail  at  the  service  level,  identifying  relevant  technology,  describing 
relevant  technologies  and  important  issues,  ensuring  interoperability,  and  focusing  on  cost 
effectiveness.  It  is  intended  to  support  the  increased  use  of  multi-level  security  in  DoD  systems. 
[Ref.  DISSP  1991] 

C2  Architecture  for  SDIO  Segments.  The  Strategic  Defense  Initiative  Office  (SDIO) 
has  issued  a  Fixed/Mobile  Segment  (FMS)  Standard  to  be  used  in  the  design  of  all  fixed  and 
mobile  ground  segments  for  the  Strategic  Defense  System  (SDS).  Such  segments  include  the 
Ballistic  Missile  Defense  Command  Center,  the  Service  Component  Command  Center,  die 
Regional  Operations  Centos,  die  Element  Operations  Centers,  and  the  Ground  Entry  Points.  This 
document  covers  open  hardware  and  software  architecture  and  software  and  user  environments. 
Standards  prescribed  in  the  FMS  document  include  [Ref.  SDIO  1991]: 

•  Electrical  interfaces:  RS-232,  RS-422/423,  RS-449,  IEEE  488. 1/.2,  MIL-STD- 1881- 
114  or  MIL- STD- 188,  ISO  8802.3  or  ANSI  X3T9.5  (Fiber  Distributed  Data 
Interface),  and  MIL-STD-1553  (data  bus). 


Backplanes:  Versa  Module  Europe  bus  (VMEbus)  (IEEE  P1014)  or  VME  Extension 
for  Instrumentation  (VXIbus,  IEEE  PI  153).  The  selection  of  VMEbus  is  to  provide 
future  growth  to  FUTURbus  (IEEE  896.1).  This  may  require  a  VMEbus-to- 
FUTURbus  bridge  compliant  with  IEEE  P1014.2. 


Protocols:  TCP/IP  (MIL-STD- 1788  and  MIL  STD-1777)  or  as  available  GOSIP 
(FIPS- 1 46)-compliant  protocols. 

Human-computer  interface  (HCD:  X- Window  System  implementation  (FIPS- 158)  of 
OSF/Motif  featuring  the  direct  manipulation  of  windows,  icons,  data,  menus,  and 
objects  within  the  windows  (primarily  a  "point-and-click"  system  of  direct 
manipulation  that  minimizes  typing.  HCI  complies  with  MIL-STD-1472  except  where 
there  are  conflicts  with  OSF/Motif,  Motif  Style  Guide,  and  multiprocessor 
requirements. 


Software:  Includes  the  NIST  Application  Portability  Profile  (FIPS-151),  GOSIP 
protocols  and  services  in  all  software  for  SDS  C2  ground  segments,  Ada  for  all 
software  development  (with  some  C  programming  permitted),  POSIX-compliant 
operating  systems,  database-defined  constants  (parameters),  database  management 
system  supporting  an  SQL  interface. 


Information  processing  system  security:  level  of  multi-level  security  protection  is 
TBD.  Underlying  operating  system  in  the  applications  processors  meets  DoD 
5200.28-STD  for  controlled  access  protection  (class  C2). 


19.11.5  US  Defense  Data  Network  (DDN) 

Packet  Switching  for  DDN.  The  US  Defense  Communications  Agency  has 
implemented  an  X.25  packet-switched  protocol  for  the  Defense  Data  Network  (DDN).  This 
protocol  includes  the  use  of  the  US  DoD- unique  protocols  for  Layers  3  and  4,  namely  the  Internet 
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Protocol  (IP)  and  the  Transmission  Control  Protocol  (TCP).  DDN  supports  over  50,000  users  of 
a  DoD-unique  electronic  mail  (E-Mail).  DDN  contains  a  set  of  physically,  proccdurally,  and 
cryptographically  secured  packet  switching  segments  for  classified  E-Mail  in  the  Defense 
Integrated  Secure  Network  (DSNET)  (e.g.,  DSNET-1,  DSNET-2,  DSNET-3).  There  are 
additional  segments  for  unclassified  E-Mail  [e.g..  Military  Network  (MILNET)  and  Advanced 
Research  Projects  Agency  Network  (ARPANET)].  Local  area  networks  (LANs)  are  connected  to 
the  DDN  by  gateways  or  hosts  using  the  DoD  IP. 

Defense  Message  System  (DMS) — Upgrades  for  DDN.  The  US  has  initiated 
[Ref.  DCA  1989c;  MROC  3-88  1989]  a  project  called  the  Defense  Message  System  (DMS)  that 
will  eventually  integrate  DDN  with  the  Automatic  Digital  Network  (AUTODIN).  DMS  will  phase 
in  [Ref.  DCA  1988a]  such  protocols  and  services  as  US  GOSIP,  ITU-TS  X.400  Message 
Handling  System,  High-Level  Data  Link  Control  (HDLC)  for  subscribers,  new  asynchronous 
protocol(s)  with  reliable  transfer  for  subscribers,  and  ITU-TS  XJ00  Directory  Services.  TCP/IP 
protocols  will  be  phased  out  Initially  (Phase  I)  a  US  DoD-unique  security  program  called 
BLACKER  will  be  implemented  at  the  host-to-host  level,  which  will  ultimately  result  in  an 
integrated  DSNET.  Later  (1993)  DDN  will  consist  of  MILNET  (unclassified)  segments  and 
DSNET  (classified)  segments  connected  by  BLACKER-protected  gateways. 

The  following  general  requirements  have  been  validated  by  the  DMS  Multicommand 
Required  Operational  Capability  (MROC)  in  1988: 

•  Connectivity  and  interoperability 

•  Guaranteed  delivery  and  accountability 

•  Timely  delivery 

•  Confidentiality  and  security 

•  Sender  authentication 

•  Integrity 

•  Survivability 

•  Availability  and  reliability 

•  Ease  of  use 

•  Identification  of  recipients 

•  Message  preparation  support 

•  Store  and  retrieval  support 

•  Distribution  determination  and  delivery. 

In  November  1991,  DISA  prepared  a  draft  DMS  Required  Operational  Messaging  Characteristics 
(ROMC)  document  to  specify  the  messaging  characteristics  that  are  derived  from  the  13  general 
requirements  identified  above.  The  ROMC  is  solution  independent  and  develops  quantitative 
characteristics  based  on  baseline  DMS  requirements  and  from  engineering  estimates.  [Ref.  DISA 
1991] 

An  OSI  Transition  Han  has  been  prepared  for  die  DMS.  The  April  1991  draft  of  this  plan 
defines  transition  goals,  constraints,  activities,  dependencies,  and  schedule  for  die  transition  of  die 
DMS  to  an  architecture  and  supporting  environment  that  employs  the  US  GOSIP.  It  documents 
the  activities  necessary  to  transition  DMS  hardware  and  software  components,  protocols,  formats, 
and  procedures  to  an  OSI-based  capability,  while  providing  for  interoperability  between  the 
baseline  capability  and  the  OSI-based  capability  during  the  transition  period. 
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Beginning  with  the  Baseline  in  1989,  the  plan  identifies  three  transition  phase  (1990-94, 
1995-2000,  and  2001-2008).  The  major  capabilities  and  changes  included  in  the  plan  are  X.400 
messaging,  X.500  Directory  Services,  management  capability,  AUTODIN-to-DDN 
interconnectivity,  Allied  interoperability,  tactical  interoperability,  and  AUTODIN  phase  out.  Phase 
I  augments  the  1989  Baseline  with  initiatives  to  bridge  the  gap  between  AUTODIN  and  the  DDN 
and  to  improve  base-level  automation. 

Phase  II  will  include  X.400/X.500  individual  and  organizational  messaging  with  the  SDNS 
Message  Security  Protocol  (MSP)  protection  (vice  distinct  AUTODIN  and  E-Mail  in  the  first 
phase).  The  Base  Information  Transfer  System  (BITS)  will  begin  to  be  deployed  at  the  base  level 
in  Phase  II.  Most  but  not  all  of  die  Baseline  and  Phase  I  components  will  be  phased  out  This 
evolution  continues  and  is  completed  in  Phase  m.  [Ref.  MITRE  1991] 

Defense  Message  System  (DMS).142  The  US  DoD  is  fielding  a  highly  distributed 
and  integrated  directory  service  based  on  the  ITU-TS  X.500  and  ISO/IEC  9594  Directory 
Specifications.  The  first  application  to  be  served  by  the  directory  will  be  the  Defense  Message 
System,  which  is  based  cm  the  CCITT  X.400/ISO/IEC  10021  messaging  standard.  This  directory 
service  will  replace  several  other  directories:  the  paper  directories  of  the  Automatic  Digital 
Network  (AUTODIN)  and  the  WHOIS  directory  on  the  DoD  Internet  The  DMS  directory  is 
expected  to  evolve  to  a  DoD-wide  Directory  and  will  be  used  to  support  other  network  and 
application  services.  Comprehensive  directory  services  are  essential  to  assist  users  in  finding 
resources,  including  X.400  user  addresses.  The  Directory  enables  such  queries  to  be  made  in  a 
logical  fashion  much  like  looking  up  a  person's  name  in  the  telephone  directory  to  find  his  or  her 
telephone  number. 

The  target  architecture  for  DMS  is  based  on  the  1993  edition  of  the  CCITT  X.500  and 
ISOIEC  9594  Directory  specifications,  the  1988  CCITT  X.400  and  1990  ISO  10021  messaging 
standard,  MSP,  STANAG  4406,  and  ACP  123.  MSP  was  developed  as  a  cooperative  project 
between  government  and  industry  under  the  sponsorship  of  NSA.  MSP  provides  confidentiality, 
data  origin  authentication,  integrity,  access  control,  for  messaging,  non-repudiation  with  proof  of 
origin,  and  non-repudiation  with  proof  of  delivery. 

The  X.500  Directory  consists  of  a  distributed  network  of  DSAs  that  collectively  contain 
information  about  real-world  objects  in  the  Directory  Information  Base  (DIB).  Each  DSA  has 
knowledge  of  at  least  one  other  DSA  as  a  source  of  information  that  die  first  DSA  does  not  contain. 
The  Directory  is  queried  by  Directory  User  Agents  (DUAs),  the  access  interface  for  directory  users 
that  may  be  a  person  or  a  computer  program.  Generally,  only  a  Directory  administrator  will  have  a 
DUA  that  is  permitted  to  update  user  and  operational  information — such  as  access  control 
information — while  other  users  may  have  limited  access. 

The  current  DoD  policy  is  for  all  X.400  users  to  have  the  P772  content  type  supported  by 
their  user  agents.  The  P772  content  type  adds  military  extensions  to  the  standard  P22  content  type. 
ACP  123,  which  replaces  ACP  127,  specifies  X.400  profiles  and  procedures.  (ACP  127  specifies 
the  message  format  now  used  by  US  allies.) 

DMS  has  worked  in  national  and  international  directory  groups  to  add  access  control, 
replication,  and  systems  management  to  the  Directory.  The  final  meeting  for  the  1993  edition  of 
the  Directory  Specifications  was  held  in  October  1992.  The  text  is  collaborative  and  has  been 


142  This  aectkm  is  bawd  on  excopu  Cram  [Gardner  1993). 
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approved  by  ISO;  when  the  text  has  been  approved  by  CC ITT,  it  will  be  published.  In  the 
meantime,  editor’s  text  is  available  from  the  ISO  Rapporteur.  Features  added  in  1993  include  the 
features  needed  by  DMS,  and  products  supporting  these  new  features  are  expected  soon. 

Enhancements  to  the  X.400  and  X.500  standards  are  needed  in  order  to  standardize  several 
key  features  for  the  Directory  in  commercial  off-the-shelf  products.  Among  the  enhancements  to 
the  standards  arc  the  following: 

•  Enforcement  of  consistency  between  aliases  and  the  entries  to  which  they  correspond 

•  Management  of  directory  services  and  the  system  components  that  underlie  them 

•  Rule-based,  administratively  imposed  access  control  in  the  X.500  Directory  standard 

•  Changes  to  the  X.400  standard  to  allow  capability  information  to  be  stored  with  each 
originator/recipient  address 

•  Standardization  of  X.400  static  routing  information  to  be  stored  in  the  Directory 

•  Confidentiality  of  directory  information. 

US  DoD  Tactical  Packet  Switching  Systems.  The  following  summarizes  the 
packet  switching  systems  employed  by  the  Services  for  tactical  applications  [Ref.  Pennington 
1993]: 

•  The  Army’s  Mobile  Subscriber  Equipment  (MSE)  Tactical  Packet  Network  (TPN) 
overlay  will  provide  an  in-theater  data  communications  capability  for  command  and 
control.  The  TPN  uses  X.25  packet  switch  technology  and  DoD  protocols.  Fielding 
began  in  FY92. 

•  The  Air  Force  Tactical  Secure  Data  Communications  (TASDAC)  system  will  provide 
secure  data  transmission  among  forward  and  deployed  Air  force  units  and  fixed  base 
parent  organizations.  The  TASDAC  system  will  attach  workstations  over  802.3 
LANs,  and  use  COTS  IP  routers  as  external  interfaces.  TASDAC  will  implement  DoD 
protocols,  with  provisions  for  evolution  to  GOSIP  in  the  future.  Fielding  was 
projected  to  start  in  FY93. 

•  The  Navy’s  Copernicus  architecture  defines  Navy  command,  control, 
communications,  and  computer  systems.  This  architecture  will  be  implemented 
beginning  in  FY93,  and  will  revolutionize  information  exchange  in  the  shore  and  afloat 
environments.  One  important  emphasis  of  Copernicus  is  to  move  away  from 
traditional  Navy  stove-pipe  systems.  An  initial  capability  may  include  shipboard 
routers. 

•  The  Marine  Corps  Tactical  Communications  Distribution  Node  (TCDN)  will  provide  a 
front-end  capability  for  resolution  of  protocol  differences  between  Marine  and  other 
Service  systems.  The  Marine  Corps  uses  proprietary  LANs  for  data  distribution, 
attaching  host  systems  only  (not  workstations).  A  COTS  IP  router  is  presorted  as  the 
external  interface. 

19.11.6  Support  for  C4I  for  the  Warrior 

The  US  Joint  Staff  (J6J)  has  developed  a  concept  to  intelligently  and  uniformly  apply 
information  technology  to  facilitate  the  command,  control,  communications,  computers,  and 
intelligence  (C4I)  support  to  the  warrior.  The  concept  is  standards  based  and  focuses  on  exchange 
of  information  between  existing  C4I  systems.  Briefly,  the  capability  of  this  concept  is  described  as 
"a  fused,  real-time,  ground  truth  picture  of  the  warrior's  battle  space  and  the  ability  to  order, 
respond,  and  coordinate  horizontally  and  vertically  to  the  degree  necessary  to  prosecute  the 
warfighting  mission  in  the  battle  space."  Each  step  of  the  interoperability  transition  process  would 
involve  the  warrior  with  the  technicians  to  ensure  the  result  is  what  is  really  needed.  Following 
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refinement  of  the  concept,  the  next  step  is  development  of  a  joint  interoperability  architecture.  This 
architecture  would  fashion  the  Service  architectural  concepts  (some  are  discussed  below)  into  an 
integrated  whole,  coordinated  with  the  CIM  initiatives.  The  standardization  underlying  the 
architecture  would  specify  services  in  the  form  of  a  joint  interoperability  standard  for  the  common 
interfaces.  Included  in  the  concept  is  a  "database  in  the  ether,  which  would  have  common  access 
protocols  and  make  it  unnecessary  for  the  user  to  have  knowledge  of  the  physical  location  or  nature 
of  distribution  of  the  information  elements  being  accessed."  [Ref.  J6J  1991] 

19.11.7  Service  Architectures  and  Standards 

ATCCS  Architecture.  The  Army  Tactical  Command  and  Control  System  (ATCCS)  is 
the  US  Army's  tactical  system-of-systems  concept  As  shown  in  Figure  40,  the  tactical  systems 
are  grouped  into  five  battlefield  functional  areas  (BFAs):  maneuver  control,  fire  support  air 
defense,  intelligence  and  electronic  warfare  (IEW),  and  combat  service  support  (CSS). 


Each  functional  area  for  the  US  Army  is  planned  to  have  a  single  BFA  control  system  and  a 
number  of  subordinate  automated  and  manual  BFA  systems.  The  objective  control  systems  are 
[Ref.  Levine  1994a]: 

*  Maneuver  Control  System  (MCS).  MCS  quickly  and  accurately  moves  tactical 
information  on  the  battlefield,  allowing  a  commander  to  readily  access  information  and 
display  current  situation  reports,  intelligence  and  contact  reports  that  assess  enemy 
strength  and  movement,  as  well  as  provide  status  of  friendly  forces.  MCS  then  aids 
the  battle  staff  in  rapidly  disseminating  the  commander’s  orders.  MCS  has  been 
fielded  on  militarized  hardware  called  the  Tactical  Computer  Terminal  (TCT)  and 
nondevelopmental  item  computers  called  the  Tactical  Computer  Processors  (TCP). 
Fielding  with  the  ATCCS  Common  Hardware  Software  (CHS)  is  planned  with  the 
next  version  (V12),  planned  for  FY95. 

•  Advanced  Field  Artillery  Tactical  Data  System  (AFATPSI,  AFATDS  is  a  totally 
integrated  fire  support  command  and  control  system.  It  will  process  fire  mission  and 
other  related  information  to  coordinate  and  maximize  the  use  of  all  fire  support  assets. 
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including  mortars,  field  artillery,  cannon,  missile,  attack  helicopters,  air  support,  naval 
gunfire,  and  offensive  electronic  warfare.  AFATDS  will  provide  processing 
capabilities  from  corps  to  the  forward  observer.  AFATDS  completed  concept 
evaluation  (CE)  in  1989  and  began  full-scale  development  in  1990.  When  fielded  with 
ATCCS  CHS  beginning  in  FY94,  AFATDS  will  replace  the  Tactical  Fire  Direction 
System  (TACFIRE)  now  being  used  in  the  heavy  divisions,  and  the  Lightweight 
TACFIRE  (LTACFIRE)  now  being  fielded  to  the  light  divisions. 

•  Forward  Area  Air  Defense  (FAAD)  Command.  Control,  and  Information  (C2I). 
FAAD  is  an  integrated  system  of  weapons,  sensors,  and  C2.  It  protects  maneuver 
forces,  critical  command  posts,  and  combat  support  and  combat  service  support 
elements  from  low-altitude  air  attack.  FAAD  C2I  is  the  element  that  provides  air 
defense  C2  and  targeting  information  to  weapons  systems.  FAAD  C2I  is  a  tactical 
data  system  being  developed  with  ATCCS  CHS  that  will  develop  and  distribute  a  low- 
altitude  air  defense  (LAAD)  air  picture  and  C2  information  across  a  division  front  Its 
IOC  is  planned  for  FY94. 

•  All  Source  Analysis  System  (ASAS).  The  ASAS  is  a  ground-based,  mobile 
intelligence  processing  system  designed  to  provide  automated  support  to  the  combat 
commander  in  the  areas  of  intelligence  and  collections  management;  all-source,  target 
and  situation  analysis;  single  and  multi-source  processing  and  reporting;  electronic 
warfare;  and  operational  security,  as  well  as  support  to  the  generation  of  intelligence 
products  in  those  areas.  ASAS  is  an  evolutionary  development  effort  consisting  of 
three  blocks  designed  to  produce  an  automated  battlefield  intelligence  fusion  system 
that  fully  satisfies  Army  operational  requirements.  Elements  of  ASAS  will  provide 
seamless  support  to  warfighters  at  echelons  from  echelons  above  corps  (EAC)  to 
brigade  level.  At  the  corps  and  division  levels,  ASAS  will  operate  at  the  Analysis  and 
Control  Element.  Sanitized  intelligence  reports  and  products  will  be  available  from  the 
collateral-level  ASAS.  At  EAC,  ASAS  will  be  tailored  to  meet  unique  theater 
requirements.  At  the  maneuver  brigade  and  battalion  level,  ASAS  collateral 
workstations  will  be  employed.  ASAS  was  developed  in  the  Joint  Tactical  Fusion 
program  with  the  Air  Force,  whose  system  was  called  Enemy  Situation  Correlation 
Element  (ENSCE).  When  fielded,  ASAS  will  replace  the  Technical  Control  and 
Analysis  Center  (TCAC,  AN/TSQ-130)  that  is  being  used  in  some  heavy  divisions  in 
the  United  States  and  in  Europe. 

•  Combat  Service  Support  Control  System  (CSSCS).  CSSCS  will  provide  a  tactical 
interface  to  CSS  systems  deployed  to  the  Continental  United  States,  used  in  garrison, 
and  fielded  for  tactical  employment  IOC  with  ATCCS  CHS  is  planned  for  FY94. 

Army  Common  Operating  Environment  (ACOE).  The  ACOE,  shown  in 
Figure  41,  is  based  on  a  four- layer  architecture  that  tracks  to  the  National  Institute  of  Standards 
and  Technology  (NIST)  Applications  Portability  Profile  (APP)  and  the  DISA  Technical 
Architecture  Framework  for  Information  Management  (TAFTM)  architectures.  The  four  layers 
consist  of:  Layer  1  (Common  Hardware);  Layer  2  (Common  System  Support  Soft’  ire);  Layer  3 
[Common  Army  Battle  Command  System  (ABCS)  Support  Software  (CASS),  fon  rly  Common 
Army  Command  and  Control  System  (ACCS)  Support  Software];  and  Layer  4  (Common 
Application  Software).  Each  layer  isolates  the  functionality  and  interfaces  from  the  other  layers. 
The  ACOE  fully  supports  a  domain-specific  architecture  and  a  centric,  systematic  reuse  program 
that  implements  the  DoD  Software  Reuse  Vision  and  Strategy.  This  ACOE  architecture  enhances 
the  maintainability  of  all  Army  command  and  control  systems,  promotes  product  independence, 
protects  Battlefield  Functional  Area  (BFA)  applications  programs  from  commercial-off-the-shelf 
software  changes,  and  enhances  application  portability.  [Ref.  Levine  1994b] 
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Figure  41.  US  Army  Common  Operating  Environment  (ACOE) 


The  ACOE  Layer  1  (Hardware)  includes  computers,  displays,  printers,  facsimile,  scanner, 
LANs,  storage  devices,  special-purpose  devices,  and  tactical  communications  interface  module 
(TCIM).  Protocols  provided  by  the  TCIM  are  specified  in  Appendix  C.  [Ref.  Levine  1994b] 

Layer  2  (System  Support  Software)  of  the  ACOE  comprises  the  following  [Ref. 
Levine  1994b]: 

•  Operating  system:  POSEX -compliant  at  C2/B 1  level  with  DOS  emulation 

•  Data  management:  SQL,  IRDS,  relational  DBMS  at  C2/B 1  level 

•  Graphical  user  interface:  Motif,  DoD  HCI  Style  Guide,  X-Windows 

•  Graphics:  GKS,  PHIGS,  PHIGS  Extensions  for  X-Windows  (PEX) 

•  Communications  support:  GOSIP,  TCP/IP,  SGML,  SMTP,  CGM,  SNMP 

•  Other:  word  processor,  spreadsheet,  Ada,  C,  business  software  packages. 

The  key  component  of  the  ACOE  is  Layer  3  (CASS).  It  serves  as  the  interface  between  the 
COTS  Software  and  the  Applications  (common  and  unique)  software.  CASS  is  fully  modular 
Ada-based  software.  Version  1.2  will  be  ready  for  incorporation  into  ABCS  in  May  1994.  A  key 
portion  of  the  CASS  layer  is  the  Message  Handling  Block,  which  contains  a  fully  automated, 
modular  Common  ABCS  Message  Parser  (CAMP).  CAMP  support  is  fully  compliant  with  the 
Joint  Interoperability  USMTF  standard  and  is  designed  to  accept  updates  to  the  latest  Joint  message 
interoperability  requirements  directly  from  the  DISA/JIEO  database  rapidly  and  at  minimal  cost 
The  CAMP  also  supports  more  efficient  data  transfer  mechanisms  such  as  bit-oriented  messages 
(BOM)  and  direct  transaction-based  database  element  transfers.  The  CAMP  is  essential  to  ABCS 
since  it  provides  the  functions  of  autofill  (from  the  database)  and  autoparse  (into  the  database)  of 
information  elements  critical  to  meeting  system  performance  requirements.  The  CAMP  is  presently 
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undergoing  preparation  for  Joint  Certification  and,  on  successful  completion,  it  will  be  placed  in 
the  Joint  software  repository  and  offered  to  all  of  the  Services.  [Ref.  Levine  1994b] 

CASS  has  two  sublayers:  a  lower  sublayer  (Services)  to  provide  the  interface  to  COTS 
software  and  hardware  and  an  upper  sublayer  (Functions)  to  provide  the  support  software  interface 
to  applications.  CAMP  is  an  example  of  a  Function.  Others  are  Alert,  which  captures,  queues, 
processes,  and  displays  audio/visual  alerts;  Map,  which  generates,  displays,  and  updates  map  data; 
Network  Management,  which  manages  and  configures  network-related  parameters;  and 
Workstation  Management,  which  manages  and  controls  workstation  functions  including  the 
configuration  parameters.  The  Service  Sublayer  comprises  the  following:  Display  Services, 
which  provide  lower-level  objects  for  controlling  the  interactive  display  using  X-Windows  and 
Motif  and  which  control  and  manage  display  objects,  menus,  and  windows;  DBMS  Services, 
which  perform  database  distribution  and  replication  and  which  interface  the  C2  applications  to  the 
common  database  management  system;  Communication  Services,  which  support  the  transparent 
communication  between  software  units  across  the  network;  and  Operating  System  Services,  which 
interface  C2  applications  to  the  UNIX  operating  system  and  which  provide  file,  library,  security, 
and  diagnostic  services.  [Ref.  Levine  1994b] 

In  addition  to  CASS,  many  common  requirements  are  being  addressed  through  the 
development  of  common  applications.  The  initial  common  applications  being  developed  are  the 
following  [Ref.  Levine  1994b]: 

•  Terrain  Evaluation  Module  (TEM) — Provides  each  system  the  ability  to  view  maps, 
generate  overlays,  have  three-dimensional  visualization  of  terrain,  show  intervisibility, 
and  other  similar  map  and  terrain  related  functions.  It  automates  the  creation, 
modification,  display,  and  use  of  overlays  combined  with  raster-  or  vector-format 
maps  in  selected  projections.  It  supports  terrain  queries  and  terrain  evaluation  using 
spatial  data.  A  common  mapping  toolkit  is  planned  for  TEM. 

•  Operations  Plan/Operations  Order  Module — Automates  the  five-paragraph  main  body 
and  the  battlefield  functional  area  (BFA)  annexes.  Key  features  include  the  ability  to 
build  the  scheme  of  maneuver  graphically  and,  if  necessary,  automatically  translate  it 
to  text. 

•  Movement  Control  Module — Automates  convoy  planning  to  include  management  of 
transportation  assets,  creation  of  configurations,  routing  and  scheduling  of  movement, 
and  in-transit  visibility. 

•  Briefing  System  Generator  Module — Automates  creation,  modification,  display,  and 
presentation  of  tactical  briefings,  including  maps,  unit  and  graphic  symbols,  and 
provides  a  linkage  to  system  databases. 

The  standards  for  the  ACOE  are  summarized  in  Table  75. 

ATCCS  Common  Hardware  and  Software  for  the  ACOE.  Supporting  ATCCS 
arc  three  types  of  communications  systems.  The  first  is  single-channel  combat  net  radio  (CNR). 
The  Army  has  fielded  VHF/FM  radios  such  as  the  AN/PRC-77  and  AN/VRC-12  family  of  radios 
and  is  deploying  the  Single-Channel  Ground-Air  Radio  System  (SINCGARS).  The  second  type  is 
an  area  switched  telephone  system  called  the  Mobile  Subscriber  Equipment  (MSE)  that  also  has 
mobile  subscriber  capabilities.  A  packet-switched  data  communications  overlay  for  MSE  is 
currently  being  added  for  data  communications.  The  third  type  of  communications,  used 
exclusively  for  data  transmission,  is  called  the  Army  Data  Distribution  System  (ADDS)  and 
consists  of  the  Enhanced  Position  Location  Reporting  System  (EPLRS)  and  the  Joint  Tactical 
Information  Distribution  System  (JTIDS).  The  data  rate  for  EPLRS  will  be  2,400-3,600  bits/sec. 
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In  addition  various  types  of  local  area  networks  are  provided  for  local-command-post  and  intra¬ 
system  communications.  [Ref.  Levine  1994a] 


Table  75.  ACOE  Open  Systems  Environment  Standards  Summary 
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The  Common  Hardware  and  Software  (CHS)  Program  has  selected  an  initial  set  of 
components  for  the  COE  based  on  die  needs  of  the  A70CS  program.  The  ATCCS  implementation 
of  the  ACOE  is  shown  in  Figure  42.  Layer  1  is  the  CHS  common  hardware.  The  ATCCS 
computers— the  Portable  Computer  Unit  (PCU)  and  the  Transportable  Computer  Unit  (TCU) — are 
based  on  a  32-bit  Motorola  68020  microprocessor,143  a  32-bit,  3  Mbit/s  data  bus,  a  33-in  floppy 
disk  drive,  and  a  40-  or  100-Mbyte  removable  hard  disk  cartridge.  The  PCU  supports  1-2  million 
instructions  per  second  (MIPS)  and  4-20  Mbytes  of  random  access  memory  (RAM),  whereas  the 
TCU  supports  2-4  MIPS  with  4-16  Mbytes  of  RAM.  The  Standalone  Display  Unit  (SDU)  is  a  16- 
in  monitor  with  two144  configurations:  monochrome  display  with  a  direct  (RS-232)  connection  to 
a  PCU  or  TCU  or  color  monitor  device  (CMD)  with  keyboard  and  connection  to  die  standard  (ISO 
8802.3)  local  area  network  (LAN).  The  PCU  has  a  25-line  (9-in)  built-in  display.  The  stand¬ 
alone  Hard  Disk  Unit  (HDU)  is  a  152-Mbyte  disk  drive  with  an  Institute  of  Electrical  and 
Electronics  Engineers  (IEEE)  488  interface.  The  Adaptive  Programmable  Interface  Unit  (APIU) 
provides  four  modems  with  multiple  interface  options  (e.g.,  wire,  RS-232,  RS-449,  COMSEC, 


143  A  68030  microprocessor  is  optional,  supporting  up  to  8  MIPS  (at  a  33  MHz  dock  rate). 

144  Other  options  include  16-  or  19-in  high-resolution  color  monitor  with  eight  planes  (the  standard  is  six 
planes).  A  12-in,  four-plane  option  is  also  available. 
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combat  net  radio,  packet  switching).  The  Handheld  Terminal  Unit  (HTU),  designed  as  a  digital 
entry  device  for  forward  units,  weighs  7-10  lb  and  supports  up  to  four  modems. 


Figure  42.  Current  Implamantation  of  ACOE  for  ATCCS  with  CHS 

The  ATCCS  CHS  Layer  2  software  is  provided  with  the  NDI  hardware  and  includes  both 
UNIX  and  MS  DOS  environments  (the  HTU  supports  only  MS  DOS).  Layer  2  has  an  Ada 
environment  with  programming  support  tools  and  standard  tools  accessible  via  bindings  in  Ada  for 
graphics  [e.g.,  Graphics  Kernel  System  (GKS)  and  database  management  (e.g.,  Starbase  and  SQL 
query  interfaces)].  Layer  2  also  provides  handlers  and  access  codes  for  the  communications 
hardware  and  software  (e.g.,  APIU,  LAN).  Protocols  for  ATCCS  are  summarized  in 
Appendix  C. 

Army  Global  Command  and  Control  Systems  (AGCCS).  The  Army  component 
of  the  Joint  Global  Command  and  Control  System  (GCCS)  is  the  AGCCS.  The  AGCCS  will  be 
built  from  applications  programs  developed  by  the  Army  WWMCCS  Information  System  (AWIS), 
the  Standard  Theater  Army  Command  and  Control  System  (STACCS)  (which  in  turn  evolved  from 
UTACCS  and  AC2IS),  and  the  Echelon  Above  Corps  (EAC)  portion  of  the  Combat  Service 
Support  Control  System  (CSSCS).  The  request  for  proposal  (RFP)  to  migrate  these  three  systems 
into  AGCCS  is  currently  in  preparation  with  contract  award  planned  for  IQ  FY95.  The  primary 
scope  of  this  effort  will  be  to  evolve  these  stand-alone  systems  into  a  suite  of  modular  applications 
(such  as  logistics,  medical,  personnel.  Theater  Army  Special  Operations  Support,  Mobilization  and 
Development,  Army  Status  of  Readiness  and  Training,  Transportation  Asset  Management,  etc.) 
that  execute  on  the  ACOE,  and  interface  with  common  applications  and  other  shared  components 
of  the  ABCS.  Descriptions  of  the  three  AGCCS  components  are  as  follows  [Ref.  Levine  1994b]: 
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•  AWIS  fulfills  the  Army's  strategic  C2  requirement  for  software,  hardware,  and 
databases  for  the  implementation  of  the  Joint  Operations  Planning  and  Execution 
System  (JOPES)  and  other  joint  service  systems  that  support  the  Commanders-In* 
Chief  (CINCs)  and  Joint  Chiefs  of  Staff  (JCS).  In  addition,  AWIS  modernizes  the 
Army’s  C2  system  supporting  conventional  military  planning  and  execution. 

•  STACCS  is  a  peacetime  and  go-to-war  system,  primarily  aimed  at  assisting  a  theater 
commander  in  the  execution  of  crisis  and  wartime  EAC  sustainment  and  operational 
maneuver  functions.  STACCS  also  interoperates  with  the  Global  Command  and 
Control  System  (GCCS),  sister  services,  multinational  and  ATCCS  Battlefield 
Functional  Area  Control  Systems  (BFACS)/ABCS,  and  other  command  and  control 
systems.  The  current  implementation  of  the  ACOE  for  STACCS  is  shown  in 
Figure  43. 

•  CSSCS  (EAC)  will  consolidate  and  collate  the  vast  quantities  of  data  required  to 
integrate  situational  awareness  of  the  combat  service  support  mission  areas.  CSSCS 
will  provide  strategic  and  tactical  commanders  with  timely,  critical  information  on 
ammunition  and  fuel  supplies,  medical  and  personnel  status,  transportation, 
maintenance  services,  general  supply,  and  other  field  services. 
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Figure  43.  Current  Implo mentation  of  ACOE  for  STACCS 


Army  Battle  Command  System  (ABCS).  The  ABCS  requirement  is  for  a  standard 
modular  system  and  application  software  supporting  a  “tailorable”  suite  of  functional  applications 
residing  on  the  ACOE  and  common  hardware  platforms  in  order  to  meet  a  specific  set  of 
commander’s  information  needs  in  the  execution  of  a  specific  mission  or  task.  ABCS  will  link 
strategic,  theater.  Joint,  and  allied  C2  systems  across  the  full  range  of  battlefield  and  operations 
other  than  war  functions.  The  ABCS  is  the  emerging  Army  concept  for  the  Army  “system  of 
systems”  utilizing  a  seamless  architecture  evolving  from  the  ATCCS  from  echelons  above  corps 
(EAC)  through  brigade  and  below.  [Ref.  Levine  1994b] 
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ABCS  Migration  Strategy.  The  ABCS  baseline  carrier  is  the  ACOE,  which  is 
substantially  in  synchronization  with  standard  operating  environments  of  all  the  other  Services. 
The  echelons  corps  and  below  (ECB)  portion  of  ABCS  is  known  as  the  ATCCS  Battlefield 
Functional  Area  Control  System  (ATCCS  BFACS),  which  comprises  MCS,  ASAS,  AFATDS, 
FAAD  C2I,  and  CSSCS  (Corps  and  Below).  The  ATCCS  BFACS  will  evolve  from  the  current 
suite  of  ATCCS  “systems"  to  interoperable  applications  running  on  the  ACOE.  Significant 
systems  engineering  and  programmatic  analysis  is  currently  in  progress  by  the  US  Army  Program 
Executive  Officer  for  Command  and  Control  Systems  (PEO  CCS)  to  achieve  this  migration.  This 
strategy  is  being  developed  to  determine  the  most  cost-effective  cut-over  points  for  each  of  the 
systems  into  an  integrate  ABCS,  taking  into  consideration  the  current  programmatic  status  of  each 
system.  AFATDS,  ASAS,  and  CSSCS  are  currently  in  development  and  under  contract  ASAS 
successfully  completed  initial  operational  test  and  evaluation  (IOT&E)  in  1993,  while  AFATDS 
and  CSSCS  will  complete  IOT&E  in  1994.  The  migration  process  has  commenced  with  the 
maneuver  battlefield  functional  area.  The  Maneuver  Control  Block  IV  RFP  is  in  the  final  stages  of 
preparation,  and  is  written  in  response  to  ABCS  requirements.  Initial  fielding  of  the  maneuver 
application  of  ABCS  is  planned  in  1995,  with  accelerated  fielding  to  the  Army,  making  maximum 
use  of  previously  fielded  (MCS  Block  III)  hardware.  [Ref.  Levine  1994b) 

Integrated  Meteorological  System  (IMETS).  IMETS  is  a  low-density  single¬ 
function  weather  correlation  and  reporting  system  specifically  designed  and  implemented  to 
support  the  commander  and  soldier  via  full-time  interoperability  with  ABCS  and  the  US  Air  Force 
Global  Weather  Service  (USAFGWS).  IMETS  is  Army  owned  and  operated  by  USAFGWS 
weather  personnel.  IMETS  employs  the  ACOE  to  the  maximum  extent  possible.  IMETS  employs 
standard  Army  shelters  and  is  fully  mobile  and  transportable.  There  are  no  plans  to  migrate 
IMETS  into  another  system  or  systems. 

Combat  Terrain  Information  System  (CTIS).  CTIS  in  the  US  Army  refers  to  the 
integration  of  the  Digital  Topographic  Support  System  (DTSS)  and  the  Quick  Reaction  Multicolor 
Printer  (QRMP)  programs.  CTIS,  a  low-density  system,  employs  the  ACOE  to  the  maximum 
extent  possible.  CTIS  receives  IMETS  weather  products  and  available  enemy  map  data,  stores  this 
information  in  a  database,  and  provides  current  map  overlays  and  terrain  and  mobility  analyses 
(using  DMA  map  products)  as  either  digital  or  paper-copy  products.  CTIS  provides  extremely 
rapid  color  products  of  the  map/terrain  output  (e.g.,  in  paper  form).  All  products  are  available 
worldwide,  since  the  CTIS  capability  is  fielded  in  standard  Army  shelters  and  is  C- 130  capable. 
There  are  no  plans  to  migrate  CTIS  into  another  system.  [Ref.  Levine  1994b] 

Counter-Narcotics  Command  Management  Control  System  (CN/CMS). 
CN/CMS  is  a  Joint  DoD/Drug  Enforcement  Agency  (DEAVDepartment  of  Justice  (DoJ)  program. 
The  Army  is  the  executive  agent  for  this  system;  PEO  CCS  is  the  Army  implementor.  CN/CMS 
provides  computer  and  secure  voice  functionality  to  DoD,  DEA,  DoJ  and  other  special  users  at 
DoD,  Department  of  State  (DoS),  and  law  enforcement  agencies  in  the  continental  United  States 
(CONUS)  and  outside  the  continental  United  States  (OCONUS)  in  support  of  counter-narcotics 
operations.  Up  to  40  sites  in  16  countries  (to  include  US)  are  planned  to  be  completely  installed 
and  fully  operational  by  30  September  1995.  There  are  no  migration  plans  for  the  CN/CMS, 
although  the  system  employs  the  ACOE  to  the  maximum  extent  possible.  CN/CMS  will  be  the 
target  system.  [Ref.  Levine  1994b] 
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USAREUR  Command  Center  System  (UCCS).  UCCS  provides  an  integrated 
information,  message,  map,  and  briefing  development  and  display  capability  at  the  CINC  level 
Rgure  44  shows  the  current  implementation  of  the  ACOE  for  UCCS. 
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Figure  44.  Current  implementation  of  ACOE  for  UCCS 


MTACCS  Architecture.  The  Marine  Tactical  Command  and  Control  System 
(MTACCS)  concept  is  shown  in  Figure  45.  One  of  the  tactical  C2  systems  is  specifically  assigned 
the  role  of  a  force-level  control  system  to  support  Marine  Air-Ground  Task  Force  (MAGTF)-levd 
C2.  Central  to  MAGTFC2  is  ADP  support  for  a  MAGTF  Database  developed  from  information 
provided  in  dm  four  functional  areas.  These  are  Ground  C2,  Aviation  C2,  CSS  C2,  and 
Intelligence.  MAGTF  C2  provides  support  to  the  Commander  for  information  fusion, 
dissemination,  and  display;  planning;  assessment;  and  tasking.  The  Marine  Corps  has  developed  a 
Common  Application  Support  Software  architecture,  similar  to  die  one  illustrated  in  Figure  42 
(above)  for  the  Army. 

The  Ground  C2  functional  area  includes  maneuver  control  and  fire  support,  as  well  as 
integration  of  position  location  information  (PLI).  Aviation  C2  includes  offensive  and  defensive 
air  support,  to  include  fixed-wing  and  rotary  wing  vertical  takeoff  and  landing  assault  support  and 
antiair  warfare.  In  addition.  Aviation  C2  includes  control  of  aircraft  and  missiles,  electronic 
warfare,  and  air  reconnaissance.  CSS  C2  provides  visibility  to  the  MAGTF  and  other  functional 
areas  as  required  on  logistic  assets  and  manpower.  Intelligence  supports  MAGTF  C2  by  providing 
information  on  enemy  positions,  orders  or  battle,  and  maneuver  indicators. 

Copernicus  Architecture.  Tables  76  and  77  illustrate  the  Copernicus  architecture 
developed  by  the  US  Navy  for  strategic  and  tactical  systems.  Copernicus  is  a  "seamless" 


Chapter  19 


487 

UNCLASSIFIED 


National  Military  Initiatives 


UNCLASSIFIED 


information  management  architecture  for  Navy  command,  control,  communications,  computers, 
and  intelligence  (C4I)  consisting  of  four  pillars:  eight  Global  Information  Exchange  Systems 
(GLOBIXSs),  the  Command-in-Chief  (CINC)  Command  Center  or  Complex,  four  Tactical  Data 
Exchange  Information  Systems  (TADIXSs),  and  the  Tactical  Command  Cotter. 


Figure  45.  US  Marina  Tactical  Command  and  Control  System  (MTACCS) 

Copernicus  capabilities  will  be  implemented  in  a  building  Mock  approach.  Each  GLOBIXS 
will  be  a  global,  virtual  (not  necessarily  physically  dedicated)  network  of  the  Defense 
Communications  System  (DCS).  Each  GLOBDCS  will  be  an  afloat  virtual  network  of  variable 
duration  (minutes,  hours,  or  days),  depending  on  the  information  exchange  load.  The  CINC 
Command  Complex  consists  of  workstations;  local  area  networks;  the  Base  Information  Transfer 
System  (BITS — a  wideband,  local,  and  metropolitan  area  network)  with  network  management, 
security,  standards,  and  protocols;  database;  and  communications  servers.  The  Tactical  Command 
Center  has  similar  capabilities  using  the  newly  developed  Communications  Support  System  (CSS) 
instead  of  BITS. 

The  Copernicus  architecture  for  the  information  systems  (CINC  Command  Complex  and 
Tactical  Command  Center),  specifically  to  address  interoperability,  has  three  parts:  (1)  standards 
and  protocols,  (2)  security,  and  (3)  network  management  As  with  ATCC1S,  the  US  Navy  has 
determined  that  homogeneity  is  not  practical  and  that  "users  need  open  systems  that  provide 
interoperability  of  products  and  portability  of  people,  data,  and  applications  across  heterogeneous 
computing  environments."  The  standards  will  include  POSIX  and  GOSIP,  but  these  have  been 
determined  as  "not  sufficient  to  address  the  full  spectrum  of  needs,  even  in  their  range  of 
applications."  As  a  result,  the  Navy  has  adopted  the  APP/OSE  developed  by  NIST  to  facilitate 
rapid  prototyping,  evolutionary  acquisition,  implementing  various  computer  architectures, 
refocusing  research  and  development,  leveraging  research  and  investment,  and  achieving  the  goal 
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of  tcaleability  of  hardware  and  software  capabilities  and  standards  that  will  be  required  in  the 
future.  [Ref.  COPERNICUS  1991] 


Table  71.  US  Navy  Copamieua  Architecture— Pillars,  lERs,  and  Functions 
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Sources:  [OP-004 1901];  lOmetein  1901). 


For  security,  Copernicus  will  use  die  capabilities  development  for  the  DoDICA,  including 
both  end-to-end  and  multi-level  security  devices.  For  network  management,  Copernicus  will  use 
MIL- STD-1813,  Network  Management  for  DoD  Communications,  June  1991,  developed  by 
NIST. 

Navy  and  Air  Force  Common  Operating  Environment  The  Departments  of  the 
Navy  and  Air  Force  had  extended  discussions  in  1993  to  explore  the  agreement  and  future 
development  of  a  COE  for  the  C2  systems  of  the  Air  Force,  Marine  Corps,  and  Navy.  Elements  of 
this  COE  are  baaed  on  both  the  Navy’s  Unified  Build  for  the  Joint  Maritime  Command  and 
Information  System  (JMCIS)  and  the  Air  Force’s  Contingency  Tactical  Air  Control  System 
(TACS)  Automated  Planning  System  (CTAPS).  A  paper  describing  these  recommendations  is 
planned  for  early  1994. 

Air  Force  Computer-Communications  Architecture.  The  architecture  currently 
addresses  base-level  applications  that  are  stove-piped  and  are  hosted  on  a  standard  base-level 
computer,  but  these  concepts  are  evolving  to  a  local  information  transfer  environment  with  support 
from  regional  processing  centers.  An  Air  Force  Corporate  Data  Dictionary  is  being  developed. 
The  Air  Force  software  architecture  is  illustrated  in  Table  78. 
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Table  77.  US  Navy  Copomlouo  Architecture — Functional  ArcMtaetm 
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Source:  The  Copernicus  ArchHctun,  Briefing  to  IDA,  Space  and  Electronic  Warfare  Directorate  OP-494  • 

(CAPTJ.R  Wood),  October  1991,  UNCLASSIFIED. 


Table  79.  US  Air  Force  Software  Architecture 
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Source:  Ak  Force  C4  Architecture,  Briefing  to  JTC3A'o  Objective  Architecture  Conference,  HQ  USAF/SCX 
(LTCJ.M.  Cmaally).  September  1991.  UNCLASSIFIED. 
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CTAPS  Common  Operating  Environment  CTAPS  was  developed  during  the 
period  1986-1991  based  on  a  comprehensive  software  standards-based  environment  These 
standards  were  adopted  in  1991  by  the  General  Officer  Steering  Committee  as  the  Tactical  Battle 
Management  (TBM)  standards.  They  comprise  the  following  [Ref.  Pait  1994]: 

•  Operating  system:  POSIX-compliant  version  of  UNIX 

•  Communications/networking:  TCP/IP  over  ISO  8802-3  (Ethernet),  with  future 
transition  to  GOSIP  standards 

•  User  interface:  OSF/Motif  and  X- Windows 

•  Data  management:  ANSI  SQL-based  relational  database  management  systems  (Oracle 
and  Sybase) 

•  Data  manipulation  and  query:  ANSI  SQL 

•  Graphics:  GKS  for  two-dimensional  graphics  with  transition  to  PHIGS  for  three- 
dimensional  applications,  when  available 

•  Mapping:  Air  Force’s  Common  Mapping  Program. 

Because  of  early  use  of  standards-based  products  (UNIX  and  Oracle)  and  die  subsequent 
evolution  of  die  standards  and  because  product-unique  extensions  were  used  by  implementors, 
elements  of  CTAPS  implementation  are  not  compliant  with  the  newest  versions  of  POSIX  and 
SQL.  This  is  planned  to  be  addressed  as  block  changes  are  made  in  CTAPS. 

The  Air  Force  is  looking  at  the  broad  issues  associated  with  choosing  standards  and 
standards-based  products  and  simultaneously  planning  the  evolution  towards  increased  openness 
in  the  underlying  architectures.  The  approach  is  to  carry  the  standards-based  approach  used  in 
CTAPS  further  through  the  use  of  open  systems  standard  applications  interfaces  (OSSAIs).  These 
OSSAIs  range  from  style  guides  to  specific  POSIX  interfaces  to  applications.  Each  OSSAI 
standardizes  dialogues,  not  the  functionality  of  applications  or  other  processes.  OSSAIs  would  be 
provided  between  applications  and  users,  operating  system,  databases,  and  other  applications.  The 
standards  being  consider  for  these  OSSAIs  are  based  on  the  POSIX  OSE  Reference  Model 
(P1003.0)  and  includes  the  following  [Ref.  Pait  1994]: 

•  POSIX  and  POSIX  application  program  interfaces  (APIs)  defined  by  ISO  9945, 
FIPS  151-1,  ISO  JTC1  SC22/WG15,  and  IEEE  P1003  projects 

•  GKS  (ISO  7942:1985),  GKS-3D  (ISO  8805:1988),  PHIGS  (ISO  9592),  PHIGS 
Plus,  and  the  PHIGS  Extensions  to  X-Windows  (PEX) 

•  X-Windows,  Xt  Intrinsies,  Xlib,  and  FIPS  158 

•  OSF/Motif  and  OPEN  LOOK  graphical  user  interfaces 

•  Reference  Model  on  Data  Management 

•  SQL  (ISO  9075;  ANSI  X3.135),  Embedded  SQL  (ANSI  X3.168),  and  evolving 
extensions  to  SQL  (SQL2  is  now  part  of  ISO  9075;  SQL3  is  under  development) 

•  RDA  and  the  SQL  specialization  of  RDA 

•  IRDS  (ANSI  X3. 138- 1988) 

•  TCP/IP  and  OSI  interconnection  standards,  to  include  X.400  MHS,  X.500  Directory, 
FTAM  (ISO  8571),  RPC,  X.25,  ISO  8802-3  (IEEE  802.3)  Ethernet  LAN, 
ISO  8802-5  (IEEE  802.5)  Token  Ring  LAN,  and  FDDI. 

Coast  Guard  Information  Systems  Architecture.  The  Coast  Guard  has  a  diversity 
of  requirements  stemming  from  the  need  to  communicate  and  interoperate  with  many  government 
agencies.  The  Coast  Guard  has  developed  a  standards-based  architecture  with  eight  aspects: 
network  standards,  hierarchical  structure,  decision  support  systems,  sensor  sub-architecture, 
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information  security,  public  data  interface,  radio  navigation  mapping,  and  command  center 
mapping. 

US  Army  Initiatives.  The  US  Army  has  a  number  of  initiatives  underway  that  address 
tactical  implementations  of  OSI  standards.  The  initiatives  are  under  the  direction  of  the 
Interoperability  and  Standards  Directorate  of  the  Communications-Electronics  Command.  The 
Army  has  an  initiative  to  evaluate  OSI  protocols  (including  possible  enhancements)  in  the  newly 
developed  Single-Channel  Ground/Air  Radio  System  (SINCGARS)  combat  net  radio  (VHF-FM). 
Specifically,  the  Army  is  examining  options  to  provide  an  automatic  voice/data  contention 
resolution  protocol  at  the  Medium  Access  Control  (MAC)  sublayer  of  the  data  link  layer  (Layer  2). 
Some  investigation  of  a  forward  error  correcting  Layer  2  protocol  is  also  ongoing.  In  addition,  an 
OSI  profile  is  being  developed  for  a  local  area  network  (T.LAN).  Further,  the  Army  has  procured 
with  its  Common  Hardware  and  Software  (ATCCS  CHS)  nondevelopmental  item  (NDI)  program 
a  number  of  commercial  OSI  implementations,  including  ISO  8802.2  and  8802.3  for  the  local  area 
network  (TCP/IP  and  other  DoD  protocols  will  be  used  initially  at  layers  above  Layer  2).  CHS  has 
ITU-TS  X.25  switched  protocols  for  wide  area  networks  (these  also  are  used  in  conjunction  with 
TCP/IP).  Finally,  the  CHS  has  a  standard  graphics  interface  and  plans  in  the  next  procurement 
phase  to  obtain,  if  possible,  a  POSIX -conform ant  operating  system.  [Ref.  CECOM  1989] 

US  Marine  Corps  Initiatives.  The  Marine  Corps  has  adopted  a  Technical  Interface 
Design  Plan  (TTDP)  for  Marine  Tactical  Systems  (MTS)  [Ref.  MTS  TTDP 1987]  that  mandates  the 
use  of  bit-oriented  messages  and  two  functional  profiles  for  protocols  in  all  its  command  and 
control  systems.  One  profile  for  broadcast  mode  is  designed  to  be  used  in  combat  net  radio.  It  has 
been  implemented  in  the  AN/PSC-2  Digital  Communications  Terminal  (DCT).  The  second  profile 
of  protocols  is  for  switched  mode  and  was  developed  from  the  Joint  Tactical  Communications 
Program  (TRI-TAC)  Interface  Control  Documents.  This  profile  has  been  implemented  with  the 
Unit  Level  Tactical  Data  Switch  (ULTDS).  The  switched  profile  is  also  being  implemented  with 
the  Tactical  Air  Operations  Module  (TAOM)  and  a  developmental  system  for  air  operations — 
Advanced  Tactical  Command  and  Control  Center  (ATACC).  Although  not  fully  OSI  conformant, 
the  two  MTS  profiles  are  based  on  several  OSI  standards  (ISO  3309,  ISO  7809,  and  ISO  4335). 
The  Marine  Corps'  approach  to  data  communications  standards  and  profiles  follows  the  OSI 
seven-layer  model  and  incorporates  military  features  not  covered  within  the  ISO  standards. 

Army  and  Marine  Corps  Initiatives  in  Fire  Support  The  Army  and  Marine 
Corps  are  cooperatively  building  an  Advanced  Field  Artillery  Tactical  Data  System  (AFATDS), 
which  is  going  through  initial  operational  test  and  evaluation  and  which  has  a  major  Army  decision 
milestone  at  the  end  of  1994.  AFATDS  will  replace  the  Tactical  Fire  Direction  System  (TACFIRE) 
in  the  Army,  which  is  currently  in  Version  10  (V.10).  Both  Services  have  fielded  an  interim 
system  for  fire  support  for  battalion  fire  direction  centers.  In  the  Army,  this  system  is  known  as 
the  Lightweight  TACFIRE,  since  it  has  the  capability  of  Battalion  TACFIRE  in  a  portable,  military- 
specification  workstation.  In  the  Marine  Corps,  this  system  is  known  as  Marine  Corps  Fire 
Support  System  (MCFSS).  Both  run  software  compatible  with  V.10  TACFIRE,  including 
TACFIRE  messages  and  protocols  (similar,  but  not  identical,  to  the  messages  and  protocols  of 
STANAG  4202  and  STANAG  5620).  Both  systems  use  RS-232C  physical  interfaces  and  ISO 
8802-3  (IEEE  802.3)  with  TCP/IP  for  local  area  networks  interconnecting  these  devices.  Both 
Services  use  combat  net  radio  (CNR)  to  exchange  digital  data  (and  voice) — the  Marine  Corps  uses 
VRC-12  and  PRC-77  radios,  while  the  Army  uses  these  together  with  SINCGARS.  Eventually 
the  two  systems  will  be  identical  and  known  (in  the  Army,  at  least)  as  the  Interim  Fire  Support 
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Automation  System  (IFSAS).  Eventually,  it  is  intended  to  implement  the  MIL-STD-188-220  and 
Variable  Message  Format  (VMF)  (see  Appendix  C)  interfaces.  Study  is  also  being  made  of 
interface  to  tactical  packet  switches,  whose  protocols  are  described  in  Appendix  C.  [Ref.  PNL 
1994] 

19.11.8  DoD  Internet  Protocols 

DoD  Protocol  Suite.  Figure  46  shows  the  DoD  Internet  protocol  suite.145  The  upper 
layer  protocols  providing  user  functionality  support  file  transfer  [File  Transfer  Protocol  (FTP),146 
MDL- STD- 1780];  electronic  mail  [Simple  Mail  Transfer  Protocol  (SMTP),  MIL-STD-1781];  and 
remote  system  access  [TELNET  Protocol,147  MIL- STD- 1782).  The  middle  layers  provide  a 
reliable  host-to-host  transport  protocol  [Transmission  Control  Protocol  (TCP)  MIL- STD-1778]  on 
top  of  a  connectionless  (CL)  internetworking  protocol. 
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Figure  46.  DoD  Protocol  Suite 


T 

000 

PROTOCOLS 


NETWOfNNQ 

access 

PROTOCOLS 


1 


No  lower  layer  protocols  are  specified  in  the  DoD  protocol  suite — it  uses  whatever 
protocols  are  required  to  access  the  network  to  which  it  is  attached.  Thus,  for  example,  the  DoD 
protocol  suite  uses  the  Ethernet™  (ISO  8802.3  CSMA/CD  Media  Access  Control  for  a  coaxial 
cable  10-Mbps  LAN)  protocol  to  operate  of  a  local  area  network  and  the  DDN  implementation14* 
of  the  ITU-TS  X.23  protocol  (X.25  Packet  Level  Protocol,  ISO  8208)  and  the  HDLC  LAPB 
(ISO  7776)  procedures  to  operate  over  a  wide  area  packet  switching  network.  Although  DoD 


145  The  Ogam  and  information  for  this  aectioo  and  the  following  aections  on  US  GOSIP  and  proposed  mixed 
stacks  for  Army  CCISa  ia  taken  from  “Use  of  OSI  Protocols  for  US  Army  Tactical  Command  and  Control 
Applications,"  Richard  Nieporent  and  Bntfesh  Misfara,  The  MITRE  Corporation,  Proceedings  of  the  SHAPE 
Technical  Centre  Military  OSI  Symposium,  6-8  June  1990,  NATO  UNCLASSIFIED. 

146  FTP  provides  a  simple  application  for  tmsfer  of  ASCII,  EBCDIC  sod  binary  files. 

147  TELNET  Protocol  provides  a  simple  scroll-mode  terminal  capability. 

14>  The  DON  Implementation  of  X23  was  provided  by  Bob  Beraoek  and  Newman.  It  is  alao  planned  for  use  in 
the  Mobile  Subscriber  Element  (MSE)  for  Army  artn  communicationt. 
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protocols  are  not  international  standards,  they  have  become  a  de  facto  open  standard  in  the  US — 
almost  every  vendor  provides  the  DoD  protocols  in  their  version  of  the  UNIX  operating  system. 
The  DoD  protocols  are  also  included  in  the  ATCCS  Common  Hardware  and  Software  (CHS) 
procurement  and  are  specified  for  use  over  the  CHS  IEEE  802.3  (ISO  8802.3)  tactical  LAN. 
Finally,  the  DoD  protocols  are  used  by  the  MSE  packet  switched  network  (PSN). 

The  DoD  protocol  suite  has  two  drawbacks  for  their  use  in  tactical  CCISs: 

•  They  are  not  US  GOS IP  compliant.  It  would  be  necessary  for  implementations  of  the 
DoD  Protocols  to  undergo  an  expensive  and  time-consuming  transition  to  satisfy  the 
GOSIP  mandate.  In  particular,  the  battlefield  functional  area  (BFA)  applications  will 
have  to  be  modified  to  use  the  functionality  of  the  GOSIP  protocols. 

*  GOSIP  Application  Layer  protocols  provide  more  functionality  than  the  DoD 
protocols.  Moreover,  more  effort  is  now  being  committed  by  the  nations  for  the  OSI 
protocols  than  by  the  US  in  the  DoD  arena.  As  new  OSI  protocols  are  developed  that 
meet  tactical  communication  requirements,  they  are  expected  to  be  incorporated  in 
GOSIP.  Thus,  future  versions  of  GOSIP  are  expected  to  provide  considerably  more 
functionality  than  the  DoD  protocol  suite. 

Version  2  of  US  GOSIP.  Figure  47  summarizes  the  US  GOSIP  protocol  suite  for 
Version  2  (see  Section  16.1.3  for  the  complete  diagram).  The  applications  supported  are  the  same 
as  the  DoD  protocols:  file  transfer  (FT AM,  ISO  8571),  electronic  mail  (MHS,  ITU-TS  X.400- 
scrics  1984  recommendations;149  and  MOTIS,  ISO  10021  and  9066],  and  the  Virtual  Terminal 
Protocol  (VTP,  ISO  9040  and  9041).  Also,  like  the  DoD  protocol  suite,  a  transport  protocol 
(Transport  Class  4,  ISO  8073)  is  specified  that  will  provide  reliable  host-to-host  communications, 
and  a  CL  network  protocol  (CLNP,  ISO  8473)  is  specified  for  internetworking.  Unlike  the  DoD 
protocols,  US  GOSIP  provides  for  the  Layer  7  Association  Control  Service  Element  (ACSE, 
ISO  8650),  connection-oriented  protocols  for  the  Presentation  Layer  (ISO  8823,  Layer  6),  and 
connection-oriented  protocols  for  the  Session  Layer  (ISO  8327,  Layer  5). 

However,  unlike  the  DoD  protocol  suite,  GOSIP  explicitly  specifies  a  number  of  network 
access  protocols,  including  IEEE  802  (Logical  Link  Control,  ISO  8802.2;  CSMA/CD,  ISO 
8802.3;  Token  Bus,  ISO  8802.4;  and  Token  Ring,  ISO  8802.5)  for  communications  over  a  LAN 
and  the  X.25  protocol  for  wide  area  packet  switch  network  communications. 

There  is  one  major  disadvantage  to  using  GOSIP  in  Army  CCISs  now.  The  MSE  PSN 
internetworking  capability  for  tactical  area  communications  can  not  be  used  with  GOSIP,  since 
GOSIP  has  a  different  internetworking  protocol  (CLNP)  than  the  DoD  protocol  suite  (IP).  Access 
to  the  MSE  PSN  will  still  be  possible  using  a  direct  interface  to  the  tactical  LAN. 

Mixed  Protocol  Stacks  for  Future  Army  CCISs.  The  US  Army  is  developing  an 
automated  Army  Tactical  Command  and  Control  System  (ATCCS)  for  the  tactical  battlefield. 
Communications  connectivity  for  the  ATCCS  will  be  provided  by  the  US  Army's  local  and  wide 
area  tactical  communications  networks.  A  protocol  suite  must  be  selected  for  the  ATCCS  that  can 
interface  to  these  tactical  networks  and  support  a  wide  range  of  tactical  communications 
applications.  A  mixed  protocol  suite,  consisting  of  OSI  upper  layer  protocols  operating  with  the 
US  DoD  transport  and  internetworking  protocols  (TCP/IP),  has  been  recommended  to  support  the 


149  US  GOSIP  1.0  and  2.0  mandate  use  of  X.400(MHS)-I984.  US  GOSIP  3.0  is  expected  to  require 
X.400(MHS)-1988. 
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required  ATCCS  functionality  and  interoperability  and  provide  a  direct  migration  path  to  US 
GOSIP  and  the  NATO  militarized  OSI  protocols. 


Figure  47.  US  GOSIP  Protocol  Suite,  Version  2 

Figure  48  shows  a  proposed  mixed  suite  of  protocols  for  ATCCS.  The  upper  three  layers 
consists  of  the  GOSIP  Session,  Presentation,  and  Application  Layers.  The  same  FTAM,  X.400, 
and  VTP  Application  Layer  protocols  are  specified  as  in  GOSIP.  The  middle  protocol  layers  are 
the  same  as  in  the  DoD  protocol  suite:  TCP  and  IP.  Also,  as  in  the  DoD  protocol  suite,  the  lower 
layer  protocols  (Physical,  Data  Link,  and  Network  Layers)  are  unspecified. 
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The  mixed  protocol  suite  has  the  increased  functionality  of  the  GOSIP  Application  Layer 
protocols,  without  sacrificing  compatibility  with  the  MSE  PSN.  No  changes  will  be  necessary  in 
BFA  applications,  when  ATCCS  transitions  to  GOSIP,  since  they  would  already  use  the  GOSIP 
Application  Layer  protocols.  [Ref.  Nieporcnt  1990] 

A  Convergence  Protocol  [Request  for  Comment  (RFC)  1006,  ISO  Transport  Service  on 
Top  of  the  TCP,  Version  3,  1987]  is  needed  to  interface  the  GOSIP  upper  layer  protocols  to  the 
DoD  internetworking  protocols.  The  Convergence  Protocol  provides  OSI  Transport  Class  0  (TPO) 
along  with  a  packetization  protocol.150  This  protocol  is  commercially  available  in  Version  6.0  of 
the  ISO  Development  Environment  (ISODE). 

19.12  Identification  of  Efforts  to  Evaluate  the  Performance  of  Civil  Standards 
for  Military  Use 

This  section  identifies  a  number  of  papers  submitted  in  June  1990  to  the  Military  OSI 
Symposium  at  SHAPE  Technical  Centre  that  describes  analytical  and  demonstration  efforts  to 
evaluate  the  performance  of  OSI  and  other  protocols  for  use  in  military  systems.  These  papers 
should  be  consulted  for  detailed  results. 

19.12.1  Tactical  Communications  Requirements  and  OSI  Applications131 

The  issue  of  whether  or  not  tactical  message  delivery  requirements  can  be  met  by  the 
deployment  of  OSI  applications  in  the  tactical  environment  does  not  have  a  simple  answer.  A 
recent  study  conducted  on  behalf  of  the  US  Army  examined  the  various  attributes  of  FTAM  and 
X.400  from  the  perspective  of  tactical  communication  systems  and  requirements.  Both  FTAM  and 
X.400  provide  highly  reliable,  in-sequence  data  delivery,  but  they  provide  no  guarantees  about  the 
delivery  delay.  It  was  concluded  that  if  delivery  delay,  rather  than  reliability,  is  the  dominant 
requirement  for  a  specific  application,  then  consideration  should  be  given  to  the  use  of 
connectionless  application-layer  services,  which  is  allowed  by  GOSIP. 

It  was  also  concluded  that  since  real-world  applications  are  seldom  monolithic,  it  is  unlikely 
that  all  of  the  requirements  of  a  specific  application  can  be  met  by  a  single  GOSIP  application,  such 
as  FTAM  or  X.400.  Considering  the  broad  range  of  message  length  and  delivery  delay 
requirements  of  most  tactical  applications,  it  is  likely  that  both  high-performance  messaging  and 
data  transfer  capabilities  will  be  required  in  most  environments.  In  addition,  deployment  of  some 
form  of  connectionless  application-layer  protocol  appears  necessary  to  meet  near-real-time 
application  needs,  where  near-real  time  is  defined  as  highly  reliable  delivery  within  about  1  minute. 

Tactical  Communications  and  OSI  Protocols.  The  study  found  that  some  of  the 
tactical  radio  systems,  such  as  MSE  and  SINCGARS  (with  appropriate  host  processing  add-ons) 
have  sufficient  bandwidth  and  processing  power  to  support  deployment  of  OSI  protocols.  On  the 
other  hand,  given  the  requirements  of  the  tactical  applications,  OSI  applications  such  as  X.400  and 
FTAM  require  substantial  networking  resources  to  support  their  requirements.  Considering  the 
strict  delivery  requirements  of  some  of  the  tactical  applications,  it  appears  that  standard  OSI 
applications  would  not  always  provide  the  high  performance  messaging  and/or  data  transfer  that 
would  be  needed  in  the  tactical  environment.  Standard,  streamlined,  high  performance  protocols 


1 50  Since  TCP  is  a  stream-oriented  protocol  and  TPO  is  a  block -oriented  protocol,  the  packetization  protocol  is 
needed  to  preserve  the  OSI  packet  boundaries. 

1 5 1  Based  on  Thin  Stacks  for  Military  Tactical  Radio  Applications,  September  1993  [MITRE  19931. 
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and  applications  could  be  developed  for  use  throughout  the  tactical  environment  and  interoperated 
with  standard  OSI  applications  through  application  gateways. 

Communication  Protocol  Alternatives.  Since  tactical  systems  have  limited 
processing  and  transmission  resources,  three  methods  of  reducing  the  demand  placed  on  these 
resources  by  OSI  protocols  were  considered:  functional  thinning,  layer  reduction,  and  header 
encoding. 

In  the  functional  thinning,  or  "thin-stack”  approach,  the  idea  is  to  reduce  transmission  and 
processing  requirements  by  carefully  examining  the  functions  provided  by  each  of  the  upper  layers 
in  the  protocol  stack  and  eliminating  those  that  are  unnecessary.  It  was  determined  that  creation  of 
a  "thin  stack”  provides  no  benefits  with  regard  to  reducing  the  required  protocol  transmission 
bandwidth.  Although  such  modifications  may  require  little  new  software  development,  the 
resulting  "thin  stacks”  will  not  be  commercial  or  government  off-the-shelf  (COTS/GOTS),  and 
therefore,  many  of  die  benefits  of  deploying  GOSIP  in  the  tactical  environment  would  be  negated. 

The  idea  in  the  layer  reduction  approach  is  to  combine  upper  layer  protocols  into  a  smaller 
number  of  layers  in  order  to  reduce  processing  and  transmission  needed  to  coordinate  die  activities 
of  the  various  layers.  This  reduction  seems  to  provide  benefits  related  to  reducing  the  processing 
bandwidth  required  for  supporting  the  OSI  protocols,  but  the  reduction  in  the  transmission 
bandwidth  overhead  achieved  may  not  be  significant  Furthermore,  such  radical  alterations  of  the 
OSI  protocol  stack  would  introduce  interoperability  problems  with  full  OSI  stack  implementations. 

In  the  header  compression  approach,  the  idea  is  to  simply  compress  the  headers  required  by 
each  of  the  layers  in  order  to  reduce  the  number  of  bits  that  must  be  transmitted  between  systems. 
Header  compression  via  bit  mapping  appears  to  be  infeasible  because  it  adds  to  die  processing  load 
and  also  creates  a  strategic/tactical  interoperability  problem.  Header  reduction  via  die  packed 
encoding  rules  (PER)  appears  to  be  a  good  option  in  that  it  represents  a  one-for-one  replacement  of 
the  basic  encoding  rules  (BER),  which  is  already  a  requirement  of  GOSIP. 

Summary  of  Results  and  Recommendations.  OSI  was  not  recommended  for  use  in 
combat  net  radio  (CNR)  or  comparable  tactical  radio  systems  that  must  support  near-real-time 
delivery  requirements.  For  more  bandwidth  and  processing-capable  radio  systems  (e.g.,  MSE  and 
SINCGARS  with  appropriate  host  processing  add-ons),  a  full  OSI  stack  can  be  deployed  to 
service  traffic  having  less  demanding  delivery  requirements.  In  order  to  reduce  the  costs  of 
developing  a  new  OSI  profile,  the  study  recommended  that  the  DMS  OSI  profile  developed  for  the 
strategic  environment  be  considered  for  those  tactical  environments  capable  of  supporting  the  full 
OSI  stack. 

For  CNR-like  tactical  radio  systems,  it  does  not  appear  that  any  level  of  OSI  protocol 
functional  thinning  would  result  in  a  protocol  suite  that  would  be  capable  of  supporting  the  strictest 
message  delivery  requirements  of  the  tactical  environment.  Development  of  a  tactical  application 
protocol  (TAP)  designed  specifically  for  the  highly  motnle/near-real-time  messaging  supported  by 
the  CNR  systems  should  be  considered.  The  development  of  this  protocol  could  be  tied  into  die 
ongoing  work  on  the  Digital  Message  Transfer  Device  (DMTD).  Effort  should  be  made  to  ensure 
that  any  protocols  dev  sloped  for  the  tactical  environment  will  support  mobile  routing  requirements 
needed  to  support  internetworking  for  tactical  communication  systems. 

OSI  can,  however,  be  used  within  the  tactical  switched  systems  to  support  die  less  time- 
critical  message  transmission  requirements.  X.400  has  a  clear  application  use  in  the  tactical 


Chapter  19 


497 

UNCLASSIFIED 


National  Military  Initiative' 


UNCLASSIFIED 


switched  environment:  message  interoperability  with  DMS,  relatively  time  insensitive  messaging, 
imagery  dissemination,  and  interconnection  of  dissimilar  systems  -  an  X.400  messaging  backbone. 

Interoperability  between  those  tactical  systems  deploying  TAP  and  those  tactical  and 
strategic  systems  deploying  DMS-OSI  could  be  restored  through  the  deployment  of  dual  protocol 
stacks  in  some  (or  all)  of  the  switched  radio  systems.  It  should  be  noted  that  this  approach  toward 
interoperability  is  necessary  regardless  of  what  non-GOSIP  protocol  stack  is  adopted  by  the  tactical 
radio  environment. 

Since  the  communication  infrastructure  requirements  to  support  deployment  of  FTAM  are 
essentially  the  same  as  those  required  for  the  deployment  of  X.400,  FTAM  can  be  deployed  in  any 
environment  where  X.400  can  be  deployed.  The  usefulness  in  a  specific  application  would  depend 
upon  the  needs  of  that  application.  For  example,  if  fetching  a  file  from  a  remote  system  is  a 
requirement  of  a  particular  application,  then  FTAM  would  provide  the  required  functionality. 

It  is  recommended  that  test  deployments  of  X.400  be  made  with  candidate  tactical  radio 
systems.  Prime  candidates,  due  to  the  applicability  of  their  architecture  and  mission,  are  MSE  and 
SINCGARS.  As  it  is  possible  to  implement  X.400  over  either  OSI  or  DoD  lower-layer  protocols, 
it  is  recommended  that  initial  testing  be  performed  over  a  Transmission  Control  Protocol/Internet 
Protocol  (TCPAP)  based  subnetwork.  This  would  allow  for  a  more  rapid,  and  less  risky,  initial 
deployment  Following  success  of  the  initial  tests,  experimental  tests  of  X.400  over  pure  OSI 
protocol  stacks  should  be  considered.  In  order  to  quickly  test  the  feasibility  of  using  X.400  in 
systems  such  as  MSE  or  SINCGARS,  it  is  recommended  that  initial  tests  use  standard  COTS 
implementations. 

19.12.2  Additional  Analyses 

Practical  Evaluation  of  OSI  Protocols.  This  paper  summarizes  work  being  done  under  the 
Robust  Protocols  Research  Programme  at  the  Defence  Research  Agency  in  the  UK  MOD.  The 
work  has  concentrated  on  X.400  and  FTAM  over  TP4,  CLNS,  and  X.25.  [Ref.  Price  1990) 

User  Performance  of  Tactical  Networks  in  the  ITDN.  User  performance  experiments  were 
conducted  in  1989  on  portions  of  the  Integrated  Tactical-Strategic  Data  Network  (ITDN) 
Demonstration  that  simulated  tactical  areas  at  echelons  corps  and  below.  The  performance  of  four 
tactical  links  [Fleet  Satellite  Communications  (FLTSATCOM),  MSE  Iine-of-sight  radio.  Tactical 
Satellite  Communications  (TACSATCOM),  and  Very  Small  Aperture  Terminal  (VSAT)]  was 
measured  at  the  protocol  level  that  most  directly  affects  the  network  user.  The  results,  though 
preliminary,  can  help  predict  the  performance  of  applications  in  tactical  nets.  US  DoD  protocols 
were  measured;  however,  the  results  may  provide  the  basis  for  informed  conjectures  about  the 
user-level  performance  of  OSI  protocols.  [Ref.  Reichlen  1990] 

Transport  Protocols  and  Internetworking  in  Low  Bandwidth  Tactical  Networks.  This 
paper  examines  the  impact  of  packet  size  on  end-to-end  functionality  (includii.g  reliable  delivery, 
packet  resequencing,  segmentation,  and  flow  control).  Tradeoffs  between  a  small  packet  size 
required  because  of  the  unreliable  media  and  a  large  packet  size  required  to  minimize  the  header 
overhead  are  considered  using  standard  transport  protocols.  The  choice  of  upper  layer  protocols 
depends  on  the  application  required  to  run  over  the  network;  for  instance,  military  messaging 
application  could  use  X.400  and  its  supporting  presentation  and  session  layers  as  specified  in  US 
GOSIP  or  the  enhanced  versions  proposed  in  ST  AN  AGs  4265-4269.  The  paper  also  assesses  the 
impact  of  the  transport  protocol  selection  on  the  network  architecture  in  an  internetwork 
configuration.  [Ref.  Bahnji  1990] 
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20.  SUMMARY  ISSUES  FOR  STANDARDS  SURVEY 

This  section  summarizes  deficiencies  in  standards 
coverage  noted  elsewhere  in  this  document  for  the  1 1  service 
areas:  programming  services,  user  interface  services,  data 
management  services,  data  interchange,  graphics  services, 
network  services,  operating  system  interface  services,  security 
services,  system  management  services,  distributed  computing 
services,  and  internationalization.  It  also  addresses  additional 
areas,  such  as  the  application  program  interfaces  (APIs)  and  the 
external  environment  interfaces  (EEls). 

The  discussion  in  this  section  is  derived  primarily  from 
the  NIST  Application  Portability  Profile  [Ref.  APP  1993]. 

Additional  information  was  derived  from  the  DoD  Technical 
Reference  Model  for  Information  Management  [Ref.  TRM 
1993],  and  the  draft  MIL-STD-xxx  on  OSE  Profile  [Ref.  JIEO 
MIL-STD-xxx  1992]. 

20.1  Software  Engineering  Services 

Software  engineering  services  (Chapter  4)  include  programming  languages  and  language 
bindings  and  computer-aided  software  engineering  (CASE)  environments  and  tools. 

There  are  international  standards  for  most,  but  not  all,  of  the  commonly  used  programming 
services.  Although  ISO  and  the  US  Government  have  adopted  ANSI  X3.1S9,  Programming 
Language  C,  there  are  potential  compatibility  problems  between  C  and  C++.  The  other  standards 
are  stable.  However,  Ada  is  undergoing  a  revision  process  and  some  aspects  of  the  current 
language  may  not  be  upwardly  compatible  with  its  successor,  Ada  9X.  Moreover,  COBOL  is 
currently  limited  in  real-time,  operating  system  and  communications  components. 

There  is  no  standard  set  of  guidelines  for  using  the  features  of  the  Ada  programming 
language;  without  guidance,  applications  written  in  Ada  may  have  unpredictable  portability.  Ada 
bindings  are  needed  for  many  interfaces  (e.g.,  GUI  toolkits,  OSI  Application  Layer  functionality, 
CDIF,  SGML,  X.25,  TCP/IP).  They  have  been  completed  for  GKS  (ISO  8651-3),  PHIGS 
(ISO  9593-3),  and  SQL  (ISO  9075:1992),  and  are  at  the  DIS  level  for  GKS-3D  (DIS  8806-3) 
and  CGI  (DIS  9638-3).  Ada  bindings  for  X,  SQL,  and  IRDS  (ISO  10728  WDAM  2)  are 
underway.  IEEE  P1003.5  is  currently  defining  Ada  bindings  only  to  POSLX.l  and  not  to  the  other 
POSIX  standards.  P1003.20  is  reported  to  be  developing  an  Ada  binding  to  POSIX  real-time 
extensions. 

All  fourth  generation  languages  (4GLs)  are  proprietary.  Portability  of  4GL  products 
requires  open  standardization  of  languages  and  bindings. 

Standards  have  not  been  developed  for  languages  used  for  certain  technologies  and 
application  areas.  These  areas  might  include  languages  used  in  artificial  intelligence  (standards  for 
LISP  and  Prolog  have  been  developed  but  not  for  other  languages)  and  used  for  interfaces  to 
specific  COTS/NDI  software.  LISP  is  more  popular  in  the  United  States  while  Prolog  is  more 
popular  in  the  United  Kingdom  and  Europe,  posing  potential  interoperability  problems. 
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Standards  for  software  development  environments,  including  CASE  tools  and 
environments,  are  in  the  early  phases  of  development.  Some  are  currently  restricted  to  interfaces 
between  tools  while  others  address  entire  environments.  Standards  are  needed  for  integrated 
(computer-aided)  software  engineering  environments  (ISEEs)  and  tools,  to  include  systems  and 
programs,  for  automated  assistance  in  developing  and  maintaining  software,  conducting  design 
work  and  analysis,  creating  program  code,  testing,  documenting,  prototyping,  and  communicating 
within  groups.  The  interfaces  among  these  tools  include  services  for  storing  and  retrieving 
information  about  systems  and  exchanging  this  information  among  the  various  system 
development  environment  components.  ECMA’s  PCTE  and  associated  reference  model  is  widely 
supported  by  vendors  in  Europe.  The  Ada  Programming  Support  Environment  (APSE) 
specifications  can  be  mapped  to  this  reference  model.  The  work  of  defining  interfaces  among 
various  software  components  is  still  incomplete  and  in  a  state  of  flux.  For  example,  there  is  as  yet 
no  consensus  on  the  type  of  data  model  necessary  to  support  the  information  structures  for  the 
environment.  The  extent  to  which  environments  such  as  PCTE  and  CAIS  can  evolve  and  be 
tailored  is  unknown.  Moreover,  CAIS  is  suffering  from  a  dearth  of  conforming  commercial 
products.  Tool  interfaces  based  on  commercial  products  may  lack  flexibility. 

Standards  for  KBS  do  not  exist.  Software  repository  standards  to  facilitate  reuse  do  not 
yet  exist.  This  could  have  an  adverse  effect  on  a  COTS/NDI  acquisition  strategy  by  making  NDI 
software  difficult  to  identify. 

Software  engineering  standards  that  address  the  software  development  process  and 
development  methods,  and  ultimately  software  quality,  are  in  the  early  phases  of  the  international 
standardization  process.  It  will  be  at  least  3  years  before  a  foundation  for  these  standards  is 
established.  To  date,  none  address  the  development  of  expert  systems. 

20.2  User  Interface  Services 

Of  all  the  service  groups,  standards  for  the  user  interface  services  (Chapter  5)  are  the  least 
mature.  This  area  suffers  from  a  general  lack  of  standards  for  toolkits  and  UIMS  and  at  the  API 
level  itself.  API  directions  likely  to  be  taken  over  the  next  5-10  years  are  uncertain.  GUIs  remain 
in  the  research  stage.  Standards  for  window  management  are  only  emerging.  While  X-Windows 
still  has  not  reached  the  stage  of  becoming  an  international  standard,  work  is  progressing. 
X-Windows  has  wide  support  in  the  United  States  and  elsewhere,  but  the  implementations  are  not 
standardized.  Moreover,  most  of  the  X-Window  functionality  is  available  only  at  a  low  level,  too 
low  for  most  application  programming.  The  Extensible  Virtual  Toolkit  (XVT)  is  one  of  many 
toolkits  that  provide  a  higher  level  API  to  window  system  functions  that  is  window-system 
independent.  There  arc  as  yet  no  standards  for  the  “look  and  feel"  for  application  software  for  the 
upper  layers  (Presentation  and  Dialog)  of  the  user  interface  system  reference  model  (see 
Section  5.3). 

Some  issues  are: 

•  Is  there  a  requirement  to  establish  a  common  look  and  feel  for  user  interfaces?  Does 
such  a  requirement  come  from  the  functional  requirements,  the  training  requirements, 
or  from  the  users  as  a  separate  operational  requirement? 

•  Is  it  appropriate  to  adopt  a  de  facto  standard,  such  as  one  set  of  X-Window  interfaces? 
The  user  interface  services  area  may  be  one  case  in  which  de  facto  standards  must  be 
used  in  lieu  of  international  standardization. 
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20.3  Data  Management  Services 

Data  management  services  include  the  data  dictionary/directory  component  for  accessing 
and  modifying  data  about  data  (i.e.,  metadata),  the  database  management  system  component  for 
accessing  and  modifying  structured  data,  and  the  distributed  data  component  for  accessing  and 
modifying  data  from  a  remote  database.  [Ref.  APP  1993] 

While  the  ANSI  standard  (ANSI  X3.138-1988)  and  FIPS  136  are  the  same,  ISO  is 
working  on  an  Information  Resource  Dictionary  System  (IRDS)  specification  (IRDS  Framework , 
ISO  10027)  that  is  significantly  different  in  some  respects  from  the  ANSI  standard.  FIPS  156 
does  not  completely  specify  interface  services  for  a  data  dictionary/repository — it  specifies  only  the 
user  interface.  ANSI  X3.183  (ISO  10728),  IRDS  Services  Interface,  provides  an  API  to  IRDS 
and  is  appropriate  for  metadata  interchange  with  a  DBMS  and  between  an  IRDS  and  application 
programs.  ANSI  X3.193,  IRDS  Export-Import  File  Format,  supports  schema  and  metadata 
interchange  among  IRDS-compliant  databases,  among  IRDS  and  CASE  tools  with  repositories  or 
dictionaries,  and  between  IRDSs  and  application  programs.  Additional  functionality  is  needed  for 
IRDS,  to  include  the  capability  to  manage  object-oriented  data  structures  and  to  provide  for 
enhanced  communication  of  information  between  applications  and  other  data  management  tools.  A 
major  revision  of  IRDS,  sometimes  called  IRDS2,  is  underway  and  is  expected  to  provide  such 
functionality. 

A  standard  relational  DBMS  interface  is  provided  by  Database  Language  SQL  (FIPS  127-2 
and  ISO  9075:1992,  sometimes  known  as  SQL2),  which  incorporates  ANSI  X3.138:1989  (SQL) 
and  ANSI  X3.168  ( Embedded  SQL),  together  with  additional  features  for  schema  manipulation, 
dynamic  SQL,  exception  handling,  enhanced  integrity  constraints,  transaction  management,  and 
data  administration.  Not  yet  addressed  are  access  to  remote  heterogeneous  sites  (see  below  on 
RDA)  and  distributed  database  management  Also  needed  are  tools  for  the  support  of  object- 
oriented  data  management  such  as  triggers,  assertions,  user-defined  types,  domain  and  table 
hierarchies,  and  stored  procedures.  While  the  scope  of  SQL3  (whose  standard  is  expected  to  be 
agreed  in  1995)  is  not  yet  defined,  it  is  expected  to  support  some  of  these  requirements. 

Distributed  database  access  is  supported  by  Remote  Data  Access,  ISO  9579.  RDA  is  used 
to  establish  a  remote  connection  between  an  RDA  client  acting  on  behalf  of  an  application 
program,  and  an  RDA  server,  interfacing  to  a  process  that  controls  data  transfers  to  and  from  a 
database.  The  goal  is  to  promote  the  interconnection  of  applications  with  database  systems  within 
heterogeneous  environments,  with  emphasis  on  an  SQL  server  interface  that  can  provide 
interoperability  between  different  SQL  servers.  The  client/server  approach  of  RDA  is  one  of 
several  architectures  for  remote  access;  others  may  emerge  in  data  management  standards.  RDA  as 
yet  only  specifies  the  service  and  protocol  between  a  single  client  and  a  single  server — it  does  not 
currently  specify  distributed  database  access,  nor  does  it  support  stored  database  procedures. 

The  US  DoD  has  embarked  on  an  ambitious  program  to  centralize  data  administration  and 
to  define  and  adopt  DoD- wide  standard  data  elements.  DoD  instructions  and  procedures  have  been 
prepared,  but  most  are  as  yet  only  in  draft  form.  A  DoD  data  repository  capability  has  been 
created,  but  to  date,  only  a  few  prime  words  and  data  elements  have  been  approved.  Development 
of  data  models  (e.g.,  using  the  DoD-mandated  IDEF  language)  for  information  systems  has  only 
just  begun.  The  ATCCIS  PWG  has  adopted  and  is  using  IDEF0  [FIPS  183]  and  IDEF1X 
[FIPS  184]  in  support  of  its  process  and  data  modelling  activities. 
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20.4  Date  Interchange  Services 

Data  interchange  services  establish  data  formats  for  interchange  of  documents,  graphics 
data,  and  product  description  data. 

In  the  area  of  document  exchange,  standards  exist  that  would  fulfill  an  AlS's  requirements. 
There  is  evidence  that  these  standards  arc  stabilizing  as  Document  Application  Profiles  (DAPs) 
begin  to  appear.  While  both  ODL  and  SGML  can  be  used  with  ODA  and  information  can  be 
transferred  between  the  two  formats,  there  are  some  advantages  to  using  SGML.  Not  only  does 
CALS  use  SGML,  but  more  commercial  products  are  available  for  it  than  for  ODL.  Moreover,  it  is 
human-readable,  preserves  user  file  divisions,  and  is  extensible  to  other  architectures.  It  also 
possesses  a  broader  information  processing  orientation  than  does  ODL,  which  is  concerned  solely 
with  document  processing.  ODA  (ISO  8613:1989)  models  are  still  incomplete,  and  there  is  still 
ongoing  work  on  the  connection  between  document  logical  structure,  layout,  and  content  Gaps  in 
ODA/ODIF  standards  (for  which  future  ISO  work  is  planned)  include:  revision  collection,  status, 
rationale,  and  author  information;  document  annotations;  automatic  content  generation  of  listings 
such  as  table  of  contents,  tables  of  figures,  indexes,  glossaries,  and  cross  references;  business 
chatting;  data  in  documents,  such  as  spreadsheets;  exchange  of  hypertext-based  documents;  and 
exchange  of  documents  that  include  voice  and  audio  information. 

Central  to  CALS  is  the  use  of  EDI  (FIPS  161;  EDIFACT,  ISO  9735:1988;  X.12-1986; 
ITU-TS  X.435:1991)  for  business  data  interchange.  EDIFACT  and  X.12  differ  in  syntax  control 
segments,  data  segments,  and  data  elements.  The  various  versions  of  EDI  are  expected  to  merge 
(in  a  future  edition  of  ISO  9735)  and  to  use  X.400-1988  messaging.  An  argument  against  using 
the  CALS  standard  as  a  model  is  that  it  is  oriented  to  technical  weapons  systems  support 
documentation  that  may  not  be  appropriate  to  an  information  system. 

The  status  of  technology  in  the  area  of  data  interchange  is  such  that  standards  do  not  yet 
manage  information  as  a  database  where  content  is  encoded  and  structure  and  form  attached. 

IGES  is  suitable  for  engineering  data  but  does  not  include  all  interfaces  for  use,  such  as  the 
interface  between  the  data  specification  and  numerically  controlled  machining  tools.  STEP 
represents  complex  data  objects  (e.g.,  technical  diagrams  and  documents)  suitable  for  product 
development  (e.g.,  for  advanced  manufacturing  machines)  from  initial  concept  design  to 
manufacturing  and  product  support 

Graphics  services  standards  all  appear  to  be  stable  and  mature  with  a  high  level  of 
consensus  and  product  availability.  However,  none  address  the  question  of  distributed  graphics. 
A  common  intermediate  standard  is  needed  to  exchange  graphics  data  stored  on  different  platforms. 

The  remaining  data  interchange  standards  areas  (geographic,  data  compression,  video,  and 
audio)  arc  far  less  stable  and  mature.  A  lack  of  standards  has  impeded  interoperability  among 
digital  cartographic  and  geographic  information  systems.  For  example,  SDTS  (FIPS  173)  has 
been  developed  for  transfer  of  digital  spatial  data  among  heterogeneous  computer  systems; 
however,  an  international  forum  (with  the  participation  of  the  US  Defense  Mapping  Agency)  has 
developed  an  alternative  specification,  DIGEST.  Agreement  on  such  a  standard  is  essential  to  the 
interoperability  of  geographical  information  systems  (GISs)  and  between  GISs  and  information 
systems  (at  least  to  import  terrain  data  and  map  graphics).  An  information  system  proponent  will 
need  to  monitor  standards  developments  in  these  areas  as  well  as  in  the  area  of  multimedia 
standards  where  standards  are  generally  lacking.  For  example,  one  promising  technology  that  has 
been  crippled  by  a  lack  of  standards  is  multimedia  mail.  (Ref.  Borenstein  1991] 
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Data  compression  standards,  particularly  JPEG  and  MPEG  have  attracted  significant 
support,  but  the  future  has  been  clouded  by  other  vendors  claiming  to  have  substantially  improved 
technical  approaches  to  compression. 

20.5  Graphics  Services 

Graphics  services  standards  all  appear  to  be  stable  and  mature  with  a  high  level  of 
consensus  rad  product  availability. 

20.0  Network  Services 

Network  services  can  be  provided  for  CCISs  using  OSI  protocols  for  electronic  mail. 
Directory,  file  management,  and  exchange  of  telematic  information  and  documents.  At  the  present 
time  there  are  not  many  high-level  services  provided  by  the  OSI  stacks,  but  the  communications 
aspects  at  lower  layers  are  mature  for  connection-oriented  services  and  maturing  rapidly  for 
connectionless-mode  services.  Only  proprietary  products  are  now  available  with  ISDN  services 
and  protocols,  and  ISDN  usage  is  not  yet  widespread  in  die  United  States.  IEEE  has  developed  a 
draft  standard  (P1003.8  Draft  6)  for  Transparent  File  Access  (TFA).  TFA-Iike  features  are 
available  in  several  products,  but  there  is  as  yet  no  common  specification  for  such  file  system 
semantics. 

Analysis  is  now  being  performed  in  TSGCE  SG9/WG2  to  identify  additional  features 
required  for  military  application  of  MHS  (see  Section  17.3.4.2).  Analysis  of  the  relationship  of 
MHS  to  ACP 129  and  ASN.l  to  ST AN  AG  5500  and  other  message  standards  is  needed.  NATO 
has  requirements  for  media  independent  data  communications  protocols  (e.g..  for  Link  1 
replacement)  that  have  not  yet  been  developed;  these  standards  could  be  applicable  to  the 
communications  services,  and  more  work  needs  to  be  done  in  this  area. 

In  a  comparison  of  the  65  service  elements  of  ACP  127,  a  recent  analysis  [Ref. 
USPR  1989]  has  identified  55  as  common  to  MHS-88.  An  additional  five  service  elements  were 
shown  to  be  related  to,  but  not  the  same  as,  those  in  ACP  127: 

•  Precedence  levels  (MHS-88  provides  an  Importance  Indicator) 

•  Message  identification  (MHS-88  provides  somewhat  different  features) 

•  Prosign  C  (MHS-88  has  an  obsolescence  indication) 

•  Bell  signal  (MHS-88  provides  a  stored  message  alert) 

•  Date-time  group  (MHS-88  has  a  submission  time  stamp). 

Five  services  provided  in  ACP  127  are  not  supported  in  MHS-88:  financial 
accountability,  service  message,  network  continuity  indication,  off-line  accountability,  and  tracer 
action. 

ISO  SC21/WG1  is  still  refining  die  OSI  Reference  Model  regarding  the  specification  of 
the  boundaries  of  Layers  1  and  2.  Some  of  the  protocols  needed  for  the  communications  services 
may  be  determined  to  lie  outside  the  Reference  Model.  These  might  include  forward  error 
correction  coding152  (several  ISO  standards  provide  for  error  detection)  and  other  mechanisms 
such  as  interleaving  of  bits  from  a  sequence  of  octets  to  reduce  die  impact  of  the  environment  on 
certain  transmission  media.  Protocols  for  handling  requirements  of  cryptographic  devices  (e.g.. 


1S2  Whether  forward  error  correction  (FEO  is  outside  of  the  OSI  Refcteace  Model  is  still  a  contentious  issue  in 
ISO,  US  PSSG,  and  NATO.  Valid  argument*  exist  for  FEC  at  either  Layer  1  or  Layer  2. 
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synchronization)  and  media  access  may  also  lie  outside  the  Reference  Model.  Standardization  of 
these  features  should,  wherever  possible,  be  accomplished  with  media-independent  standards. 

20.7  Operating  System  Services 

Operating  system  services  include  kernel  operations,  commands  and  utilities,  system 
management,  real-time  extensions,  and  security.  Four  of  these  areas  (management  is  excluded)  are 
addressed  by  POSIX.  The  POSIX  standard  provides  the  broadest  applicable  reference  model  for 
developing  portable  applications  at  the  source  code  level.  Considerable  progress  has  been 
achieved,  and  there  is  additional  work  in  process.  [Ref.  OSN  1993h] 

Standardization  of  operating  systems  appears  unlikely.  Further,  there  is  no  need  to  select  a 
standard  operating  system  for  an  automated  information  system,  since  such  a  selection  is  viewed  as 
an  implementation  issue.  When  mature,  adopting  the  POSIX  interface  standard  for  information 
systems  appears  to  be  an  attractive  option,  both  to  achieve  some  of  the  required  system  services 
and  to  promote  applications  portability  during  implementation.  Adoption  of  the  current  POSIX 
standard  would  probably  not  fully  meet  system  service  requirements.  For  example,  POSIX 
addresses  independent  operating  systems  cooperating  in  a  distributed  environment,  not  a  single 
operating  system  running  on  multiple  machines.  It  is  not  specifically  designed  for  distributed 
applications,  and  therefore  may  not  serve  an  information  system's  needs  completely. 

Moreover,  IEEE  1003.1-1988,  System  Application  Program  Interface  (FIPS  151-1  and 
ISO  9945-1)  does  not  include  the  capabilities  for  kernel  security  that  are  typically  provided  in  an 
operating  system  kernel.  Also  required  are  real-time  profiles  (IEEE  P1003.13)  and  testing 
specifications. 

Recent  developments  at  X/Open  concerning  the  UNIX  API  also  bear  watching. 

20.8  Security  Services 

While  there  is  a  great  deal  of  activity  in  standards  for  security  services,  there  is  very  little 
that  is  complete.  The  most  mature  technical  areas  are  operating  system  and  physical  layer  network 
standards,  but  even  here  the  standards  are  not  mature.  Security  in  most  other  aspects  still  contains 
areas  of  basic  research.  The  standards  that  have  been  approved  are  generally  the  umbrella 
standards,  such  as  ISO  7498-2. 

20.9  System  Management  Services 

Quality  of  Service  and  security  are  not  well  addressed  by  OSI  and  other  open  systems 
standards.  Both  of  these  sets  of  services  require  review  and  possible  modification  of  the  basic 
reference  models  for  open  systems.  They  therefore  could  lead  to  disruption  of  some  of  the 
standards  that  have  already  become  stable  under  the  existing  reference  models. 

Both  sets  of  services  may  be  supported  in  a  wide  range  of  ways,  and  several  approaches  of 
these  may  be  required  in  information  systems  to  meet  operational  requirements.  For  example, 
quality  of  service  affects  all  the  layers  of  the  OSI  Reference  Model,  and  the  associated  protocols, 
managed  objects,  and  parameters  of  the  protocol  data  units  may  all  have  to  be  extended  to  meet 
military  requirements.  Security  can  be  expected  to  impact  at  least  the  Physical,  Network,  and 
Applications  Layers  of  the  OSI  Reference  Model  (the  NATO  position)  and  other  layers  as  well 
(SDNS  also  provides  a  protocol  for  the  Transport  Layer). 

Work  has  already  begun  on  OSI  services  and  protocols  in  the  management  area.  Systems 
management  is  generally  acknowledged  to  affect  all  service  areas,  especially  operating  system 
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services  and  network  services.  The  only  consensus  achieved  to  date  for  standardizing  systems 
management  services  is  in  the  OSI  network  management  area.  Version  1  (June  1992)  of  the 
Government  Network  Management  Protocol  (GNMP)  identifies  information  required  for  managing 
implementations  incorporating  network  services  only  at  the  Physical  and  Data  Link  Layers,  and  it 
does  not  provide  a  complete  set  of  managed  object  definitions  or  the  necessary  security  features  for 
network  management 

Support  for  access  control  and  authentication  is  already  being  incorporated  into  a  number  of 
OSI  standards.  Many  other  aspects  of  security,  such  as  key  management,  still  must  be 
standardized  to  ensure  interoperability  and  to  avoid  building  the  same  functions  many  times  in 
similar  systems  (e.g.,  function-specific  information  systems)  and  in  the  applications  of  a  single 
system,  such  as  a  CCIS. 

Management  issues  can  be  expected  to  differ  for  each  of  the  technologies  being  considered 
for  information  systems.  For  example,  security  aspects  of  local  area  networks  differ  from  those 
associated  with  broadcast  radio  and  packet-switched  point-to-point  links. 

Findings  in  security  and  OSI  management  are: 

•  Standards  for  OSI  security  are  evolving,  but  the  evolution  is  slow.  OSI  standards  may 
not  be  satisfactory  in  some  areas  (e.g.,  OSI  services)  in  and  of  themselves  for  military 
applications.  They  may  need  to  be  supplemented  by  application-level  services  outside 
the  OSI  model. 

•  An  adequate  treatment  of  management  services  mav  require  modification  to  the  OSI 
Basic  Reference  Model  and  thereby  impact  many  stable  OSI  standards. 

•  Some  management  standards  are  now  stable  (e.g.,  ISO  9595,  ISO  9596;  ISO  10040, 
ISO  10164.  ISO  10165),  hut  there  is  standardization  required  in  many  additional 
areas. 

20.10  Distributed  Computing  Services 

The  effort  that  OSF  has  put  into  DCE  is  beginning  to  mature.  The  technology  will  be 
widely  available  in  the  first  half  of  1994.  Most  major  open  systems  vendors  will  offer  a  version 
interoperable  with  tire  others  on  their  UNIX  based  systems.  Many  will  also  feature  DCE  ports  on 
their  proprietary  systems,  for  example  IBM’s  OS/2.  SUN  and  Microsoft  may  be  the  only 
exceptions;  however  TRANSARC  will  provide  a  version  for  Solaris,  and  Gradient  Technologies 
will  provide  a  version  for  Microsoft  Windows. 

In  terms  of  de  facto  standardization,  UNIX  International  has  promised  to  provide  DCE 
Compatibility  in  the  near  future;  Siemens  already  provides  a  System  V  Release  4  version  of  DCE 
as  an  OSF  Reference  Model.  X/Open  is  "fast-tracking"  DCE  for  incorporation  into  its  next  version 
of  XFG.  After  being  "standardized"  by  X/Open  and  adopted  by  the  open  system  vendors,  actual 
ISO  or  ANSI  standardization  will  not  be  far  behind. 

The  current  version  of  DCE  appears  to  be  usable  for  unclassified  uses.  Care  must  be 
exercised  if  it  is  to  be  used  for  classified  uses.  The  next  year  will  see  the  definition  of  a  generalized 
security  API  for  DCE,  which  will  aid  the  implementor  in  developing  applications  that  deal  with 
classified  data.  Few  applications  utilizing  DCE  exist  Developer  kits  and  the  standardization  of  the 
application  environment  will  help  to  provide  the  impetus  so  that  applications  using  the  interfaces 
should  begin  to  appear  late  next  year. 

One  of  the  most  demanding  application  suites,  the  Distributed  Management 
Environment  1.0  has  just  been  released  to  vendors.  DME  must  still  be  tailored  to  the  DCEs  of 
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individual  manufacturers.  Printing  services  and  their  management  will  not  be  provided  until  this 
spring.  The  management  framework  is  not  due  until  late  in  1994  or  early  in  1995.  Complete 
management  services  based  on  an  integrated  set  of  services  from  DCE  and  DME  are  not  likely  until 
mid- 1995  at  the  earliest. 

This  could  be  hastened  if  the  deployment  of  the  OMG  Object  Request  Broker  and  the 
dependent  services  is  speeded.  Currently  a  number  of  manufacturers  have  ORB  products 
available.  The  new  version  of  the  ORB,  which  emphasizes  interoperability,  is  not  yet  available. 
One  might  expect  its  specification  in  1994  with  implementations  in  early  1995.  The  ORB  and  its 
associated  suite  of  object  services  should  be  available  in  late  1995  or  early  1996.  These  services, 
which  could  be  based  on  DCE,  could  stimulate  the  development  of  distributed  services  and 
applications.  If  kept  on  hack,  DCE,  DME,  and  the  ORB  should  enable  the  high  volume  production 
of  applications  by  1997. 

20.11  Internationalization 

In  the  area  of  Internationalization,  the  character  set  work  is  the  most  mature.  Some 
industry  actions  have  also  occurred.  MKS  has  announced  fully  internationalized  and  multibyte- 
enabled  versions  of  its  InterOpen  source  code  products.  These  are  InterOpen/Multibyte  POSIX 
shell  and  utilities,  InterOpen/Multibyte  SPG4  commands  and  utilities,  and  InterOpen/Multibyte 
XPG4  terminal  interface.  Single  byte  internalization  allows  text  messages,  input,  output,  and  data 
processing  to  occur  in  most  languages  for  which  a  single  byte  character  set  exists — such  as 
French,  English,  and  German.  Multibyte  internationalization  extends  this  to  accommodate  large 
repertoire  languages  such  as  Japanese  and  Chinese,  while  maintaining  support  for  single-byte 
languages.  IBM  is  the  first  company  to  license  the  internationalized  version  of  InterOpen/POSIX 
shell  and  utilities,  and  implements  this  source  code  on  its  mainframe  operating  system  OpenEdition 
MVS. 
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OVERVIEW  OF  THE  ATCCIS  ARCHITECTURE* 


The  purpose  of  this  appendix  is  to  provide  a  technical  overview  of  the  ATCCIS  architecture.  However,  this 
information  is  not  required  to  understand  the  review  of  standards  that  follows.  For  more  information  on  ATCCIS, 
the  reader  should  first  consult  the  ATCCIS  Phase  II  Final  Report  (October  1990),  the  Phase  III  Wort  Plan 
(December  1991),  and  the  Phase  III  Project  Brief  (December  1991),  from  which  this  overview  is  taken  [Refs. 
ATCCIS  1990,  ATCCIS  1991].  Table  1  identifies  the  ATCCIS  documents  that  have  been  circulated  to  the  Nations 
by  SHAPE. 

1.  BACKGROUND  FOR  ATCCIS 

1.1  ATCCIS  Purpose 

The  primary  purpose  of  the  ATCCIS  program  is  to  achieve  interoperability  between  national  automated 
CCISs  for  use  in  the  Central  Region  (CR)  at  Cwps  and  below  in  the  years  2000  and  beyond.  Two  implicit 
objectives  are  to  ensure  that  (1)  ATCCIS -conformant  systems  deployed  by  the  Nations  are  also  interoperable  with 
the  systems  being  developed  under  the  Allied  Command  Europe  (ACE)  automated  CCIS  programme  and  (2)  such 
systems  are  affordable. 

The  ATCCIS  Permanent  Working  Group  (PWG)  was  tasked  by  Supreme  Headquarters  Allied  Powers 
Europe  (SHAPE)  to  develop  an  operational  and  technical  concept  for  an  interoperable  tactical  ACCIS  that  is  based  on 
stated  operational  requirements  and  evolving  military  concepts.  The  PWG  is  comprised  of  army  officers  and  civilian 
scientists  from  seven  Nations  (Denmark,  France,  Germany,  The  Netherlands,  Spain,  United  Kingdom,  United 
States),  SHAPE,  and  Allied  Forces  Central  Europe  (AFCENT)  (with  Canada  and  Italy  as  observers)  working 
cooperatively  in  accordance  with  guidance  from  SHAPE. 

1.2  ATCCIS  Objectives 

To  satisfy  the  primary  purpose  of  attaining  interoperability,  the  ATCCIS  development  programme  must 
satisfy  four  principal  objectives: 


1  Extracted  from  the  ATCCIS  Phase  II  Final  Report  [ATCCIS  1990]. 
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a.  To  formulate  common  requirements  for  the  use  of  battlefield  information 

b.  To  ensure  that  all  international  and  multinational  users  of  critical  battlefield  information  can  exchange 
that  information  on  a  basis  that  is  mutually  agreeable 

c.  To  exchange  information  so  that  it  conveys  the  same  meaning  and  understanding  to  source  and 
recipient  alike 

d.  To  define  a  technical  architecture  capable  of  accomplishing  the  necessary  exchanges  and  transactions. 


Table  1.  Listing  of  ATCCIS  Papers  Distributed  by  SHAPE 


No. 

Class 

T»;  e 

Edi¬ 

tion 

Date 

- 

NU 

Phase  II  Work  Plan 

msm 

Sep-86 

1 

NS 

Threat 

1.0 

Mar-86 

2 

NR 

Mission  Needs  &  Objectives 

1.0 

Sep-85 

3 

NC 

Concept  (or  Survivable  C2 

1.0 

Dec-87 

4/5 

NC 

Key  Tasks 

1.0 

Oct -85 

6 

NC 

Echelons  &  Staff  Organizations 

1.0 

Jul-86 

7B 

NU 

Degrees  of  Data  Interoperability 

1.0 

Mar-86 

7F 

NU 

Databases 

1.0 

Aug-89 

7L 

NU 

Data  Management  &  Standardization 

1.0 

Jun-89 

7M 

NU 

Methodology  for  Identifying  C2  Operational  Requirements 

1.0 

Sep-89 

7N 

NU 

Standardization  of  Data  for  Interoperability 

1.0 

Sep-90 

8 

NC 

Operational  &  Functional  Concepts 

IQQH 

May-88 

10 

NC 

Information  Flow  Requirements  &  Products  for  Each  Key  Task 

mu 

Sep-90 

11 

NU 

Requirements  from  Key  Tasks 

El 

Jan-90 

12 

NR 

General  Requirements 

1.0 

Sep-88 

12A 

NR 

Security  Requirements 

1.0 

Sep-88 

13 

NU 

lERs  Among  Elements  of  Each  HQ 

1.0 

Feb-88 

14 

NC 

lERs  Between  HQs 

wnm 

Sep-90 

17 

NC 

Interfaces  to  Non-ATCCIS 

1.0 

Apr-88 

18 

NR 

Operational  Standards  for  ATCCIS  lERs 

1.0 

Sep-88 

18A 

NU 

Modernization  of  Land  Force  Operational  Standards 

1.0 

Sep-89 

22 

NU 

Architectural  Concepts 

UJj]. 

Sep-87 

23 

NU 

Requirements  Analysis 

1.0 

Sep-87 

24 

NU 

Architecture  Definition 

mu 

Oct -90 

24B 

NU 

Properties  of  TF  and  SCF 

1.0 

Dec-87 

25 

NU 

Technical  Standards  for  ATCCIS  Architecture 

ms 

Jan-92 

30 

NU 

Applicability  of  the  Architecture 

1.0 

Jan-90 

34 

NU 

ATCCIS  Communications 

1.0 

Jan-90 

34A 

NU 

Background  to  ATCCIS  Comms 

1.0 

Oct-88 

39 

NR 

Phase  II  •  Final  Report 

1.0 

Oct-90 

- 

NU 

Phase  III  Work  Plan 

1.0 

Dec-93 

• 

NU 

Phase  III  Project  Brief 

1.0 

Dec-93 

1.3  ATCCIS  Phase  II  Findings 

There  were  eight  principal  findings  of  the  Phase  II  study. 

I .  There  is  more  than  80%  commonality  in  the  key  command  and  control  (C2) 
tasks  performed  at  corps  level  and  lielow,  despite  the  fact  that  the  organization  and  structure  of  command 
posts  (Cl's)  utilized  by  the  four  Nations  differ  significantly. 


Appendix  A 


A-2 

UNCLASSIFIED 


ATCCIS  Overview 


UNCLASSIFIED 


a.  The  PWG  developed  and  harmonized  a  detailed  listing  of  the  Key  Tasks  perforated  at  tactical  echelons 
by  the  ground  forces  of  each  of  the  four  Nations.  The  PWG  also  documented  the  specific  information 
needed  by  a  particular  command  or  staff  element/cell  in  order  to  accomplish  a  given  Key  Task.  These 
analyses  demonstrate  that  the  Nations  have  common  requirements  for  the  use  of  battlefield 
information. 

b.  CR  Nations  do  not  have  a  common  way  of  expressing  their  operational  requirements  when 
participating  in  multinational  cooperative  C2  efforts.  Therefore,  the  PWG  adopted  an  ACE 
methodology.  Command  and  Control  Requirements  Analysis  (C2RA),  and  successfully  modified  it  for 
use  at  the  tactical  level.  It  appears  that  this  method  is  suitable  for  adoption  by  other  Nations  faced 
with  a  similar  requirement  Indeed,  the  ABCA  (Australia,  Britain,  Canada,  and  America)  Nations  have 
adopted  the  ATCCIS  methodology  as  their  way  ahead  for  progressing  C2-related  projects. 

2.  The  four  Nations  can  directly  correlate  those  specific  C2  processes  performed 
in,  and  the  information  exchange  requirements  (IERs)  pertaining  to,  their  respective  corps, 
division,  and  brigade  CPs  with  a  harmonized  set  of  ATCCIS  C2  processes  and  sets  of 
ATCCIS  IERs. 

a.  The  faces  of  all  Nations  must  have  a  common  understanding  of  how  C2  processes  are  performed  in 
order  to  operate  effectively  together  and  ensure  that  orders  and  directives  are  not  misinterpreted. 
Notwithstanding  national  variations  in  organization  and  doctrine,  the  detailed  analyses  revealed  that  the 
C2  processes  earned  out  by  all  four  Nations  are  essentially  common.  The  study  represents  the  first 
comprehensive  investigation  of  the  essential  and  necessary  interactions  between  the  national 
formations  and  NATO  Principal  Subordinate  Commands  (PSCs). 

b.  The  study  effort  identified  the  producers  and  users  of  nearly  3,000 
C2  Products  such  as  operations  orders  or  situation  reports.  Using  these  results,  the  IERs  were  then 
defined  for  those  national  forces  that  might  be  required  to  operate  in  coalition  with  the  forces  of  other 
Nations  or  under  the  operational  control  of  a  NATO  Headquarters  (HQ).  Requirements  have  been 
reconciled  with  the  emerging  results  of  the  ACE  A  COS  system  design  and  integration  effort 

3.  Current  C2-related  operational  standards  prescribed  for  use  by  NATO  and  the 
Nations  are  often  conflicting,  inadequately  defined,  and  ill-suited  for  international  exchange 
of  information  in  either  a  manual  or  an  Automatic  Data  Processing  (ADP)- supported  CCIS  environment 

a.  NATO  C2-related  operational  standards  have  been  compared  with  corresponding  national  instructions, 
doctrine,  and  directives.  It  was  found  that  many  of  the  standards  are  out-of-date  or  imprecisely  written. 
In  other  instances,  individual  Nations  and  formations  have  opted  to  implement  modifications  that  no 
longer  resemble  the  base  standard.  This  is  an  unsatisfactory  basis  for  progressing  either  manual  or 
ADP- supported  CCIS  programmes. 

b.  To  remedy  this  problem,  the  PWG  proposed  a  strategy  for  modernizing  NATO  C2-related  operational 
standards.  SHAPE  endorsed  the  PWG  proposal  and  forwarded  it  to  the  NATO  Military  Agency  for 
Standardization  (MAS).  Mote  work  is  urgently  required  before  this  problem  can  be  rectified. 

4.  A  NATO-wide  data  management  policy  is  required. 

a.  The  need  for  such  a  policy  is  well  established  in  NATO,  but  none  has  yet  been  promulgated. 

b.  Commonly  agreed  and  unambiguous  definitions  of  data  are  required  for  use  in  ACCISs.  Lack  of  such 
definitions  severely  inhibits  the  attainment  of  international  as  well  as  multinational  interoperability. 
Current  operational  and  technical  procedures  cannot  ensure  that  the  source  and  the  recipient  of 
information  that  is  exchanged  between  and  among  cooperating  formations  will  each  share  the  same 
meaning  and  intent  of  that  information. 

5.  A  technical  architecture  for  an  ATCCIS  can  be  defined  by  using  international 
commercial  (nonproprietary)  standards  supplemented,  where  necessary,  with  military 
enhancements  or  standards. 

a.  Given  the  existing  significant  differences  in  national  philosophy,  organizations,  funding,  and 
procurement  schedules,  it  was  determined  that  development  of  common  hardware  for  ATCCIS  would 
not  be  practical. 

b.  The  PWG  determined  that  the  most  feasible  way  for  the  technical  work  to  proceed  would  be  to  focus 
on  the  establishment  of  an  architecture  that  would  provide  a  common  basis  acceptable  to  all  Nations. 

6.  The  analysis  has  concluded  that  an  ATCCIS-conformant  system  must  be  a 
transaction  processing  system  with  a  partitioned,  partially  replicated  database. 
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a.  The  essential  nature  of  military  C2  is  the  interaction  of  commanders  and  their  staff  with  superior  and 
subordinate  formations,  by  the  manipulation  of  military  information  through  various  forms  of 
transactions. 

b.  ATCClS-conformant  systems  must  be  capable  of  supporting  applications  and  maintaining  the 
capability  for  consistent  interpretation  of  data  across  national  and  multinational  formation  boundaries. 

c.  The  interactions  that  users  of  tactical  ADP  systems  make  are  in  the  nature  of  transactions  that  are,  for 
example,  in  the  form  of  updates  to  a  database,  requests  for  information,  or  orders  to  be  issued  where 
appropriate.  Future  demands  on  transaction  processing  systems  will  probably  take  the  form  of 
decision  support. 

d.  The  architectural  concept  is  defined  in  terms  of  a  number  of  logical  facilities  that  provide  technical 
services  essential  for  the  interoperability  of  ADP  systems  that  support  the  C2  function.  The  key 
attribute  of  ATCCIS-conformant  systems  is  Basic  Interoperability,  i.e.,  the  exchange  of  infonnatioa 
that  preserves  the  meaning  and  relationships  of  the  information  exchanged.  It  is  achievable  through 
the  implementation  of  four  facilities;  the  facilities  themselves  are  defined  in  terms  of  standards, 
protocols,  and  functionality.  However,  it  is  still  loo  early  to  select  specific  interoperability 
parameters,  individual  standards,  or  stacks  of  standards. 

c.  The  sole  requirement  placed  on  tactical  communications  by  the  architecture  is  to  provide  a  standard 
network  service. 

7.  The  concept  for  the  ATCCIS  architecture  is  consistent  with  that  for  the  NATO 
Consultation,  Command  and  Control  (C3)  Architecture. 

a.  The  current  NATO  C3  Architecture  draws  heavily  on  ATCCIS  technical  proposals. 

b.  The  ATCCIS  technical  concept  is  also  compatible  with  the  draft  guidelines  for  technical  standards 
being  established  within  NATO. 

8.  Operational  and  technical  standards  necessary  for  national  implementation  are 
still  immature;  a  programme  definition  phase  is  required. 

1.4  ATCCIS  Method  of  Work  for  Technical  Analyses 

The  technical  analyses  in  ATCCIS  have  been  limited  to  those  aspects  of  the  architecture  that  appeared  to  be 
essential  to  achieving  basic  intcropcrability-the  exchange  of  information  that  preserves  meanings  and  relationsbips- 
and  the  potential  for  cost  savings  without  unnecessarily  limiting  national  implementation  options.  Provision  has 
been  made  in  the  proposed  architecture  for  supporting  a  wide  range  of  approaches  for  developing  and  implementing 
applications  to  support  operational  requirements,  but  there  was  no  attempt  to  delimit  or  specify  those  approaches. 
Technical  and  procedural  standards  were  reviewed  for  their  applicability  for  specifying  the  architecture,  but  no 
selection  of  such  standards  has  yet  been  attempted.  The  review  has  identified  standards  employed  in  NATO  and  - 
whcrc  such  standards  could  be  widely  used-in  the  Nations  for  ensuring  interoperability  and  providing  the  potential 
for  cost  savings.  Preliminary  analysis  has  been  performed  on  the  applicability  of  the  architecture  to  a  wide  range  of 
operational  configurations,  but  this  analysis  was  descriptive  rather  than  complete  in  so  far  as  covering  ail  possible 
operational  requirements  or  in  fully  validating  the  technical  aspects  of  the  architecture.  Technical  analyses  have  also 
addressed  the  impact  of  the  architecture  on  communications  and  of  communications  on  the  architecture,  but  it  is  too 
early  to  be  definitive  about  what  communications  will  be  in  place  by  A.D.  2000. 
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Key  features  of  tfae  technical  approach  can  be  summarized  as  follows: 

•  The  architecture  was  specifically  limited  to  defining  only  those  aspects  required  for  interoperability. 
The  architecture  is  not  intended  to  be  a  complete  architecture  satisfactory  for  implementation. 
Specifically,  the  architecture  does  not  define  any  application- level  facilities,  nor  does  it  define  any  user 
interfaces  or  user  interaction  with  the  database. 

•  ATCCIS  confonnancy  limits  implementations  only  to  the  extent  that  they  must  provide  the  services 
and  logical  facilities  of  the  architecture.  Thus,  the  architecture  intentionally  does  not  have  the  detail 
required  to  guide  the  choice  of  computer  architecture,  workstations,  operating  system,  database 
management  system,  tv  other  commercial  off-the-shelf  (COTS)  products.  These  aspects,  together 
with  the  definition  of  application-level  facilities  and  user  interfaces,  would  be  national  options  and 
would  have  to  be  addressed  in  national  systems. 

•  The  architecture  is,  by  design,  driven  primarily  by  the  requirement  for  interoperability.  National 
CCIS  architectures  are  expected  to  differ  depending  on  the  additional  driving  requirements  imposed  to 
meet  national  needs,  which  include  the  use  of  COTS  software,  support  common  software  development 
among  several  Nations,  or  use  a  wide  mix  of  products  from  different  vendors. 

•  NATO  has  defined  six  "Degrees  of  Interoperability,"  reflecting  the  procedures  by  which  the  transfer  of 
data  associated  with  interoperability  is  to  be  achieved.  It  has  been  generally  accepted  that  degree  5 
interoperability— automated  data  exchange  with  user-imposed  access  restrictions-is  the  mechanism 
required  by  the  Nations  and  has  been  adopted  by  the.  study  as  the  basis  for  providing  interoperability. 
Many  of  the  concepts  underlying  the  architecture  are  governed  by  the  requirement  to  implement  degree 
5  interoperability. 

2.  Fundamental  Concepts  of  the  ATCCIS  Architecture 

This  section  describes  seven  concepts  that  ate  fundamental  to  the  architecture. 

2.1  Information  Exchange 

Information  Exchange  Based  on  Information  Items.  Information  items  are  the  essential 
ingredients  for  the  performance  of  a  military  Key  Task  (both  input  and  output).  Information  exchange  today  is 
conducted  on  the  basis  of  formatted  messages  in  the  form  of  C2  Products,  which  ideally  are  composed  of  agreed 
groups  of  information  items.  However,  in  the  future,  information  exchange  between  conformant  systems  will  be 
conducted  on  the  basis  of  information  items  themselves,  and  the  required  information  aggregates  can  be  constructed 
from  these  information  items.  Information  products  in  their  entirety  constitute  a  highly  inefficient  basis  for 
information  exchange.  Note  that: 

a.  Preparation  of  information  aggregates  from  groups  of  information  items  in  performance  of  Key  Tasks 
is  the  prerogative  of  national  implementation  and  may  pot  necessarily  be  standardized. 

b.  The  definition  of  information  items  that  support  the  performance  of  Key  Tasks  is  seen  as  relatively 
stable,  whereas  the  procedures  for  performing  the  Key  Tasks  and  the  form  of  the  associated  C2 
Products  can  be  expected  to  change  more  often. 

c.  Agreement  on  die  exchange  of  information  items  that  preserves  meaning  and  relationships  is  essential 
for  interoperability,  but  agreement  on  formats  for  presenting  these  data  is  not  required  for 
interoperability. 

d.  A  C2  Product  may  be  propagated  by  creating  a  new  set  of  its  constituent  data  items.  However,  a  C2 
Product  may  also  be  propagated  more  efficiently  by  an  update  to  some  of  its  constituent  items. 

Information  Exchange  Based  on  Other  Data  Types.  Information  will  need  to  be  exchanged  for 
other  types  of  information  objects-an  object  contains  information  in  some  agreed  cootext-than  objects  based  only 
on  information  items  for  structured  data.  Examples  of  such  information  objects  ate  assessments,  briefings, 
documents  such  as  operations  orders,  video  imagery,  graphical  displays  such  as  map  overlays,  and  terrain 
representations.  Document  exchange  can  be  achieved  by  agreements  on  document  structure  and  format  without 
restricting  national  options  for  implementing  word  or  text  processing  capabilities  or  national  preferences  for  bow 
documents  are  presented  to  users. 

2.2  Information  Models 

The  architecture  will  need  to  support  several  types  of  data  models,  including  a  relational  model  for  a 
database  for  structured  data.  Since  structured  data  is  expected  to  be  present  in  all  ACCISs,  the  relational  model  will 
be  common  to  all  conformant  systems. 
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Relational  Model.  For  many  army  ACCISs,  data  arc  distributed  and  selected  parts  of  the  total  data  are 
replicated  in  a  limited  number  of  locations;  this  is  a  concept  technically  referred  to  as  a  partitioned,  partially 
replicated  database.  Since  data  arc  maintained  in  a  number  of  locations  because  the  data  originate  and  are  used  in 
different  locations,  the  connectivity  of  those  locations  cannot  always  be  guaranteed.  Unexpected  temporary  or 
permanent  loss  of  nodes  and  links  is  a  feature  of  the  military  environment.  Furthermore,  communications 
limitations  may  demand  local  caching  (storage)  for  performance  reasons.  Hence,  in  order  to  ensure  that  the  required 
data  is  available  at  a  specific  location  at  the  time  it  is  needed,  the  database  is  organized  and  maintained  as  a 
partitioned,  partially  replicated  database. 

Other  Data  Models.  The  architecture  will  need  to  support  information  models  other  than  the  relational 
nuidel  described  above.  These  could  include  object-oriented  models  for  such  data  types  as  documents,  imagery,  and 
terrain  representations.  Further,  the  architecture  will  need  to  provide  for  the  integration  of  different  types  of  data 
(e  g  ,  data  items  or  documents)  for  the  various  models.  Each  data  model  will  lead  to  a  different  type  of  database  in  an 
implemented  system. 

2.3  Information  Transfer 

Three  criteria  have  to  be  satisfied  in  order  that  Basic  Interoperability  can  be  achieved: 

•  Transfer  of  Data  There  must  be  a  means  whereby  data  can  be  physically  moved  from  the  originating 
HQ  to  another  1IQ  that  needs  that  data. 

•  Interpretation  of  Data.  There  must  be  some  means  of  identifying  the  data  so  that  the  two  (or  more) 
HQs  using  the  data  can  be  certain  they  will  all  interpret  it  in  a  consistent  manner. 

•  Management  of  the  Basic  Interoperability  Functions.  There  must  be  mechanisms  for  managing  the 
processes  involved  in  these  operations,  including  (but  not  restricted  to)  the  needs  for  security  and 
keeping  abreast  of  a  changing  metical  disposition  of  HQs. 

The  minimum  capabilities  required  to  support  these  criteria  are  ( 1)  a  mechanism  that  provides  end-to-end  transfer  of 
data,  (2)  a  mechanism  to  manage  the  storage,  retrieval,  and  interpretation  of  data,  and  (3)  a  mechanism  that  manages 
these  two  mechanisms. 

Several  types  of  transfer  mechanisms  may  be  required  for  the  various  data  types.  Database-to-database 
transactions  could  support  transfer  of  structured  data  (defined,  for  example,  by  a  relational  information  model).  Other 
transfer  mechanisms  may  be  required  for  exchange  of  such  data  types  as  documents;  candidates  are  file  exchange, 
military  message  handling,  or  electronic  mail. 

2.4  Transaction  Processing 

The  interactions  between  users  and  an  ACCIS  are  in  the  nature  of  transactions  (e.g.,  in  the  form  of  updates 
to  a  database,  requests  for  information,  or  orders  to  be  issued).  This  transactional  characteristic  of  ACCISs  will 
continue  to  apply  in  the  future  with  the  expectation  that  there  will  be  additional  demands  on  such  systems,  for 
example,  in  the  form  of  decision  aids  and  other  forms  of  automation  to  support  the  decision  process.  Therefore,  the 
principal  characteristic  of  systems  that  support  tactical  C2  is  transaction  processing. 

2.5  Support  for  Applications 

Requirements  have  been  identified  for  providing  military  services  to  users,  which  in  tum  require  the 
provision  of  decision  support  and  other  functions  to  support  the  performance  of  Key  Tasks.  The  provision  of  these 
functions  will  be  fulfilled  by  a  set  of  applications  executed  on  the  ADP  systems  supporting  the  staff  in  the 
performance  of  their  Key  Tasks. 

It  is  therefore  necessary  for  conformant  systems  to  be  able  to  support  the  execution  of  such  applications. 
Furthermore,  the  allocation  of  applications  to  particular  systems  or  pans  of  systems  should  not  be  fixed,  but  should 
have  sufficient  flexibility  to  allow  for  changing  operational  situations.  The  manner  in  which  such  applications  are 
incorporated  into  a  system  is  specified  by  the  architecture,  but  the  detailed  specification  of  the  functionality  of  any 
particular  application  is  outside  the  scope  of  the  architecture  and  may  be  a  matter  for  individual  Nations  to  determine 
for  themselves,  or  may  be  the  subject  of  separate  multinational  agreements.  Within  the  architecture,  any 
application,  irrespective  of  its  functionality,  must  conform  to  certain  rules  and  interface  standards. 

2.6  Support  for  Human-Computer  Interfaces  (HCIs) 

The  technical  capabilities  of  a  system,  and  the  information  held  within  such  systems,  are  of  no  practical  use 
unless  the  staff  users  can  gain  access  to  those  capabilities  and  information.  It  is  therefore  essential  for  systems  to 
provide  an  adequate  human -computer  interface.  Agreement  on  a  common  human-computer  interface  is  not  essential 
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for  interoperability  and  is  therefore  not  addressed  as  part  of  the  requirements  for  Basic  Interoperability.  However, 
there  are  many  benefits  to  be  obtained  by  adopting  a  common  approach  to  human-computer  interface,  inducting,  for 
example,  a  common  presentation  to  users  and  the  potential  for  common  development  of  software  for  applications. 
The  architecture  therefore  has  identified  in  outline  a  Map-Machine  Interface  (MMI)  Service  Facility  (MSF)  ao  provide 
a  common  set  of  services.  Such  a  facility  allows  the  adoption  of  a  User  Interfaoe  Management  System  (UIMS), 
providing  such  capabilities  as  window  managers  and  user  dialogue  managers  to  allow  flexibility  for  applications 
while  at  the  same  time  removing  from  those  applications  the  need  to  account  far  the  particularities  of  any  one  set  of 
equipment  for  user  interaction. 

2.7  Information  Exchange  With  Nonconformant  Systems 

Interoperation  with  nonconformant  systems  will  be  an  important  capability  of  conformant  systems  during 
the  transition  phase.  In  addition,  it  is  expected  that  there  will  always  be  some  nonconformant  systems  fielded  by  the 
Nations;  information  exchange  with  those  systems  is  expected  to  be  in  accordance  with  current  NATO  procedures 
that  use  message  text  formats  (i.e.,  STAN  AG  5500).  Such  systems  may  be  manual  or  ADP-supported,  and  the 
degree  of  interoperability  achievable  and  the  services  required  may  cover  a  wide  range.  An  additional  set  of  facilities 
has  been  identified  to  provide  for  such  interoperation,  although  no  detailed  effort  has  been  allocated  to  refining  their 
specifications.  In  order  to  achieve  interoperability  with  nonconformant  systems,  there  must  be  an  agreement  on  data 
standardization. 


3.  Overview  of  the  Architecture 

The  fundamental  concepts  on  which  the  architecture  is  based  are  identified  in  Section  2.4  and  describe  a 
transaction  processing  system  with  a  partitioned,  partially  replicated  database,  capable  of  supporting  applications  and 
maintaining  the  capability  for  consistent  interpretation  of  the  data  across  organizational  boundaries.  This  description 
of  the  nature  of  an  ATCCIS-conformant  system  is  basic  to  the  structure  of  the  architecture. 

The  architecture  is  defined  in  terms  of  a  number  of  facilities  (defined  below)  essential  for  the  interoperability 
of  ADP  systems,  which  support  the  command  and  control  function  and  provide  opportunities  for  cost  savings.  The 
facilities  are  themselves  defined  in  terms  of  functionality,  protocols,  and  standards. 

4.  ATCCIS  Faculties 

A  facility  is  a  logical  entity  that  provides  at  its  external  interface  a  set  of  related  services,  which  includes  all 
of  the  functionality  necessary  to  provide  those  services,  together  with  any  additional  functionality  required  to  relate 
one  service  to  another  or  to  maintain  the  status  and  internal  logical  properties  of  flic  facility.  The  architecture  defines 
the  logical  structure  of,  and  interrelationships  among,  the  facilities.  The  facilities  necessary  to  provide  Basic 
Interoperability  are  referred  to  as  the  Basic  Facilities,  whose  functionality  most  be  standardized  for  all  conformant 
systems. 


4.1  Basic  and  Application-Level  Facilities 

There  are  four  Basic  Facilities  in  the  ATCCIS  architecture: 

(1)  n*t«  Management  Facility  fDMFV  The  DMF  provides  functionality  to  ensure  the  proper 
management  of  data,  and  to  ensure  that  there  is  a  consistent  representation  of  data  and  data 
relationships  across  all  conformant  systems. 

(2)  Transfer  Facility  (TF1.  The  TF  provides  functionality  to  allow  different  parts  of  a  system,  or  two 
conformant  systems,  to  invoke  services  one  from  another.  TF  includes  transfer  protocols, 
services  of  the  communications  infrastructure,  and  services  to  manage  data  transfer  and 
communications. 

(3)  System  Management  Facility  fSMFV  The  SMF  provides  functionality  supplementary  to  the 
management  services  of  the  TF  and  DMF  for  control  of  part  or  all  of  a  system. 

(4)  Service  Control  Facility  fSCFV  The  SCF  provides  functionality  to  control  interactions  among  all 
other  facilities. 

The  Basic  Facilities  provide  the  three  mechanisms  identified  in  Section  22.3  (viz.,  providing  end-to-end  transfer  of 
data;  managing  the  storage,  retrieval,  and  interpretation  of  data;  and  managing  these  mechanisms)  as  the  minimum 
capability  lo  support  Basic  Interoperability. 

Application-Level  Facilities  (ALFs)  provide  the  functionality  associated  with  performing  the  automated 
parti  of  Key  Tasks  in  a  subfunctional  area  (SFA).  Within  the  architectural  model,  there  may  be  *****  ALFs 
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providing  general  application-level  services  common  to  a  number  of  subfunctional  areas  or  Key  Tasks,  and  other 
Al.l's  providing  particular  functionality  in  support  of  one  SFA  or  a  single  Key  Task.  The  extent  to  which  Key 
Tasks  in  an  SFA  arc  supported  by  automation  is  a  national  prerogative.  ALFs  could  be  national-unique,  standardized 
among  some  nations,  or  standardized  among  all  the  nations. 

4.2  Other  Facilities 

Two  additional  facilities  have  been  identified  for  the  architecture,  other  than  the  ALFs  and  the  four  Basic 
Facilities.  These  are  the  Man-Machine  Interface  (MMI)  Service  Facility  (MSF)  and  a  family  of  Input/Output 
Facilities  (IOFs).  The  MSF  provides  the  functionality  for  a  generalized  interface  between  ALFs  and  users, 
irrespective  of  the  particular  devices  used  to  interact  with  users  and  the  human-computer  interface  they  implement. 
Each  IOF  provides  an  interface  between  a  conformant  system  and  a  particular  class  of  nonconformant  systems.  There 
arc  as  yet  no  formal  operational  requirements  for  the  MSF  or  IOFs,  but  agreements  to  standardize  these  facilities 
could  lead  to  opportunities  for  cost  savings. 

4.3  Facilities  and  Operational  Activities 

Four  classes  of  activities  have  been  identified  in  the  operational  analysis  of  Key  Tasks  (WP  11)  that  need  to 
be  supported  by  ADP  functionality.  These  classes  and  their  relationship  to  the  facilities  are  as  follows: 

•  Access.  This  class  includes  all  activities  and  actions  involved  with  the  access  by  the  user  to 
information,  or  recording  information  provided  by  the  user.  It  includes  any  subsidiary  activities  and 
actions  to  enable  the  user  to  specify  and  carry  out  his  access  requirements  satisfactorily.  In  this 
context  for  an  ADP  system,  the  term  "user"  should  also  be  interpreted  as  including  any  item  of 
software  operating  on  the  user's  behalf.  The  access  class  will  be  provided  primarily  by  the  DMF, 
supported  by  human-computer  interfaces  (e.g.,  MSF),  and  ALFs. 

*  Processing.  This  class  includes  all  activities  and  actions  involved  in  the  manipulation  of  information 
to  produce  new,  or  revised  versions  of  existing,  information.  The  processing  class  will  correspond  to 
the  functionality  associated  with  performing  the  automated  parts,  if  any,  of  Key  Tasks  in  an  SFA. 
Within  the  architectural  model,  there  may  be  facilities  providing  general  application-level  services  and 
facilities  providing  particular  functionality  in  support  of  one  SFA  or  a  single  Key  Task.  This 
functionality  will  be  provided  through  ALFs.  There  may  be  a  significant  number  of  processing 
activities  and  actions  performed  manually. 

*  Transfer.  This  class  is  specifically  concerned  with  the  transfer  of  information  from  one  command  post 
or  group  of  users  to  another.  It  is  not  concerned  with  any  processing  of  the  information,  nor  with  the 
presentation  of  the  information  to  the  user,  nor  recording  updated  information  that  the  user  might 
provide.  Again,  in  this  context  for  an  ADP  system,  the  term  'user''  should  also  be  interpreted  as 
including  any  item  of  software  operating  on  the  user's  behalf.  The  transfer  class  will  be  primarily 
provided  by  the  TF  and  DMF. 

•  Control.  This  class  includes  all  activities  and  actions  concerned  with  the  management  of  the  C2 
process,  rather  than  performing  specific  actions  within  the  process.  The  control  will  be  supported  by 
the  management  services  of  TF  and  DMF,  the  SMF,  and  ALFs  with  specific  system  management 
functionality.  Interactions  among  the  other  facilities  will  be  controlled  by  the  SCF.  There  is 
expected  to  be  a  significant  number  of  control  activities  and  actions  performed  manually. 

4.4  Interaction  Between  Facilities 

Each  facility  will  provide  a  defined  set  of  services.  These  services  are  available  to  all  other  facilities  within 
the  same  ensemble  (see  below).  A  facility  that  calls  on  the  services  of  another  facility  must  do  so  by  means  of  a 
predetermined  service  call  with  a  predetermined  set  of  parameters.  The  service  requested  may  provide  an 
acknowledgment,  a  return  of  data,  or  both,  or  an  exception  condition.  The  action  of  the  called  facility  will  be 
predetermined. 

5.  Ensembles  and  Components 

5.1  Basic  Ensemble 

An  ensemble  is  a  set  of  facilities  that  includes,  as  a  minimum,  the  four  Basic  Facilities.  The  smallest 
ensemble  is  one  that  contains  only  the  Basic  Facilities  and  is  referred  to  as  the  Basic  Ensemble.  A  set  of  facilities 
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that  does  not  include  the  four  basic  facilities  (Le.,  does  not  include  tbe  Basic  Ensemble  as  a  subset)  is  not  an 
it  it  merely  »  gmnping  n t  farilitW*  that  no  pgwifirMicr 

Systems  may  be  represented  logically  as  configurations  of  ensembles.  Two  ensembles  participating  in  a 
peer  interaction  may  be  part  of  tbe  same  or  different  systems.  Tbe  TF  provides,  by  virtue  of  its  functionality,  tbe 
Unking  mechanism  between  all  ensembles. 

A  simplified  picture  of  tbe  architecture  is  depicted  in  Figure  3.  It  shows  the  relationship  between  tbe  TF 
and  tbe  other  facilities  in  two  ensembles.  Tbe  Basic  Ensembles  are  highlighted  with  bold  lines.  SMF,  SCF,  and 
DMFeacb  appear  in  all  the  mtmhie*,  whereas  the  TF  is  considered  common  to  all  the  ensembles.  Ensembles  A 
and  B  can  be  thought  of  as  tbe  facilities  at  two  physical  locations.  The  TF  includes  the  services  for  open  systems 
intenooooectioa  and  tbe  bearer  circuits  (i.e.,  communications  media). 

5.2  Interaction  Between  Ensembles 

The  TF  link*  one  ensemble  to  another.  A  facility  in  any  ensemble  has  access  to  tbe  TF.  Facilities  may 
call  on  tbe  services  of  other  facilities  that  form  part  of  tbe  same  ensemble  for  assistance.  A  facility  will  be  aware  of 
the  other  facilities  within  its  own  ensemble,  but  will  not,  in  general,  be  aware  of  the  existence  of  other  ensembles. 
However,  a  facility  can  be  made  aware  of  other  instances  of  tbe  same  facility  that  exist  in  other  ensembles,  known  as 
peer  facilities,  and  can  interact  with  those  peer  facilities  through  the  functionality  of  TF  to  assist  in  providing  its 
services.  For  example,  data  replication  and  remote  access  to  data  both  require  peer  interactions  between  data 
management  facilities.  A  facility  will  not  normally  be  aware  of  the  existence  of  the  same  facility  in  every  other 
ensemble;  indeed,  restriction  on  tbe  awareness  of  other  ensembles  will  be  one  of  tbe  mechanisms  employed  to 
control  access  and ’need  to  know.” 


Figure  3.  Facilities  of  the  Architecture 

A  facility  requiring  services  from  another  ensemble  may  call  only  on  tbe  services  of  a  peer  facility.  If  the 
services  of  a  different  type  of  facility  are  required,  the  calling  facility  must  call  on  the  local  instance  of  tbe  called 
facility;  in  the  absence  of  such  a  local  instance,  tbe  services  of  that  facility  are  not  available. 

5.3  Components  end  Their  Relationship  to  Ensembles 

A  Component  is  a  collection  of  hardware  and  software  that  implements,  as  a  minimum,  the  Basic  Facilities 
in  order  to  interoperate  with  other  Components  at  least  at  tbe  level  defined  by  Basic  Interoperability.  It  must  provide 
the  services  of  those  facilities,  either  by  implementing  all  of  those  services  itself  or  by  providing  access  to  their 
implementation  on  other  Components. 

There  is  a  one-to-one  relationship  between  Components  and  ensembles.  Specifically,  the  implementation 
of  an  ensemble  is  a  Component,  and  a  Component  implements  only  one  ensemble.  Tbe  subsets  of  an  ensemble, 
even  if  they  include  the  Basic  Ensemble,  are  not  thought  of  as  separate  ensembles  in  relation  to  tbe  Component  on 
which  they  are  implemented.  Thus,  consolidating  the  facilities  from  two  Components  onto  one  Component,  as  may 
be  required  if  one  of  them  becomes  inoperative,  is  considered  as  combining  the  two  ensembles  into  one  ensemble, 
not  implementing  two  ensembles  on  one  Component 

A  collection  of  Components  is  known  informally  as  a  system,  usually  with  a  qualifier  that  indicates  the 
basis  for  the  collection,  such  as  a  headquarters  system  or  a  national  system.  There  is  a  wide  range  of  possible 
configuration  options  for  a  headquarters  system,  from  a  single  Component  serving  all  users  through  terminals  to  a 
large  number  of  individual  workstations,  each  a  Component,  interacting  to  provide  tbe  total  requirements  of  tbe  HQ. 
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It  should  be  noted  (hat  a  set  of  workstations  connected  on  a  LAN  may  be  a  single  Component  or  each 
workstation  may  be  a  separate  Component,  depending  on  whether  the  four  basic  facilities  have  been  implemented 
once  for  the  collection  or  once  in  each  workstation.  The  choice  is  entirely  a  national  option.  In  the  case  where  each 
workstation  is  a  separate  Component,  it  is  likely  that  the  measure  of  interoperability  among  such  a  grouping  of 
ensembles  will  be  significantly  higher  than  the  measure  of  interoperability  specified  overall.  This  is  also  a  national 
choice.  Thus,  system  specifiers  arc  free  to  determine  their  requirements  independently  for  local  interoperability. 

Automated  support  of  subfunctional  areas  will  be  implemented  on  a  set  of  Components.  Data  elements 
owned  by  those  subfunctional  areas  will  be  managed  by  DMF  services  implemented  on  those  Components.  Those 
DMF  services  must  ensure  that  these  data  elements  arc  available  to  the  other  subfunctional  areas  that  require  them. 
An  SI  A  may  not  create,  delete,  or  amend  data  elements  owned  by  other  subfunctional  areas. 

5.4  ATCCIS-Conformant  Systems 

If  a  number  of  Components  are  interconnected  according  to  the  architectural  rules,  then  the  resulting  system 
itself  becomes  conformant.  A  conformant  system  will,  in  general,  comprise  a  number  of  distinct  interconnected 
Components,  each  of  which  must  conform  to  the  architecture  and  interoperate  with  other  Components  of  the  system, 
and  with  Components  of  other  systems,  according  to  the  standards  defined  by  the  architecture.  Thus,  the 
conformance  of  a  system  can  be  demonstrated  by  proving  all  its  Components  and  interconnections  to  be  conformant. 
A  conformant  system  will  remain  conformant  if  additional  conformant  Components  are  connected  according  to  the 
rules  and  standards  defined  by  the  architecture.  From  a  technical  point  of  view,  when  two  systems  are  interconnected 
they  can  be  considered  as  a  single  system.  However,  management  considerations  will  normally  differentiate  between 
the  two  systems. 

An  HQ  will  be  configured  from  one  or  more  Components.  A  Component  may  host  part  or  all  of  one  or 
more  subfunctional  areas.  Implementing  agencies  would  have  great  freedom  in  how  the  software  and  hardware  of  a 
system  might  be  designed  to  achieve  conformancy. 

5.5  System  Management 

Services  must  be  provided  to  allow  conformant  systems  to  be  configured  and  managed  so  that  users'  ADP 
needs  arc  satisfied  in  the  most  effective  manner.  System  managers  will  call  on  system  management  ALFs  to  assist 
them  in  managing  the  system  in  the  same  way  that  other  users  will  call  on  their  specific  ALFs  to  perform  their  day- 
to-day  roles. 

Several  aspects  of  a  conformant  system  will  require  data  to  relate  its  own  operations  to  other  parts  of  that 
system  or  to  other  conformant  systems.  Some  Key  Tasks  are  concerned  with  system  management  and  will 
manipulate  sets  of  information  containing  system  management  parameters.  System  management  information 
exchange  requirements  (IERs)  define  the  exchange  of  system  management  parameters.  Tables  of  system  management 
parameters  will  be  managed  by  the  DMF  with  access  rights  specific  to  the  system  management  functions.  Users, 
other  than  system  managers,  will  be  able  to  read  but  not  modify  these  tables. 

An  example  of  a  system  management  table  is  the  logical-to-physical  translation  table  that  will  be  used  by 

the  TF. 

Other  aspects  of  system  management  will  be  performed  by  the  system  managers  calling  on  management 
services  of  the  DMF  and  TF.  Most  of  the  system  management  functions,  which  will  be  offered  to  the  system 
managers  as  high-level  services  by  the  appropriate  ALFs,  will  be  effected  either  by  these  local  system  management 
services  in  TF  and  DMF  or  by  the  maintenance  and  distribution  of  local  tables. 


6.  The  Four  Basic  Facilities 

This  section  provides  technical  details  regarding  the  four  basic  facilities:  DMF,  TF,  SCF,  and  SMF. 

6.1  Data  Management  Facility  (DMF) 

The  purpose  of  data  management  is  to  (I)  represent  the  meaning  and  relationships  of  the  information  items 
required  to  perform  key  tasks,  (2)  ensure  meanings  and  relationships  are  preserved  when  information  is  exchanged 
with  another  conformant  system,  and  (3)  ensure  changes  to  data  items  arc  applied  consistently  wherever  these  items 
arc  stored.  The  DMF  needs  to  support  a  number  of  data  models,  including  a  relational  model  for  structured  data. 
These  data  models  should  be  derived  from  a  common  conceptual  schema  to  ensure  compatibility  of  the  data  objects 
and  data  elements. 
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Raqalranciits.  The  DMF  is  required  to  provide  date  from  the  A7CCIS  database  to  a  facility  in  the  same 
performing  a  service  on  behalf  of  the  user.  Further,  tbe  DMF  supports  updates  to  the  database,  replicates  a 
partition  between  ensembles,  and  copies  a  partition  for  local  use. 

Concepts.  A  replication  domain  (RD)  is  a  partition  of  the  data  owned  by  an  SFA.  The  RD  is  the 
muiifnt  unit  of  tbe  tfamhase  that  can  be  replicated  in  full.  An  RD  contains  data  from  a  single  data  model. 

A  replication  pattern  is  a  specification  of  which  ensembles  are  permitted  to  bold  a  copy  of  an  RD  other  than 
the  anpahte  owning  die  RD.  The  replication  pattern  is  one  of  tbe  mechanisms  for  providing  access  control  in  the 
architecture. 

An  access  control  domain  (ACD)  is  a  subset  of  an  RD  with  a  common  set  of  authorized  users.  A  set  of 
data  elements,  in  tfae  case  of  structured  data  with  a  relational  model,  comprises  an  ACD. 

Services.  There  are  three  primary  services  provided  by  tbe  DMF:  update  transactions,  access,  and 
replication  transactions. 

•  Update  transactions  are  performed  on  RDs  in  a  single  ensemble.  (As  a  national  option,  within  tbe 
/  same  HQ  one  update  transaction  may  update  RDs  in  multiple  ensembles.) 

y  Access  is  tbe  retrieval  of  a  set  of  values  for  specified  data  elements  (or  other  data  objects).  Access  may 

be  performed  by: 

(1)  Query,  from  an  RD  in  the  same  ensemble  as  tbe  requesting  facility 

(2)  Remote  query,  from  an  RD  in  another  ensemble  to  which  access  has  been  previously  agreed. 

•  Replication  transactions  copy  all  the  data  that  has  been  updated  within  the  RD  to  another  ensemble. 

The  services  provided  by  a  replication  transaction  may  depend  on  the  type  of  data  in  the  RD. 

By  definition,  the  physical  manifestation  of  a  source  RD  for  a  replication  transaction  is  in  a  single 
Component  and  the  physical  manifestation  of  the  target  RD  is  also  in  a  different  single  Component  Thus,  since  the 
physical  manifestation  of  an  RD  would  be  entirely  contained  in  the  database  (or  other  appropriate  data  structure 
implementing  the  data  model)  at  a  single  Component  tbe  protocols  for  a  replication  transaction  are  simpler  than  if 
the  replication  involved  sources  or  targets  with  multiple  databases  spanning  several  physical  Components.  A 
complete  list  of  DMF  services  is  provided  in  Annex  A  of  WP  24. 

Support  for  DMF  Services.  A  special  RD  (called  a  system  management  RD)  will  be  defined  to 
describe  tbe  RDs  accessible  to  each  DMF  and  to  identify  tbe  logical  addresses  of  the  physical  manifestation  of  those 
RDs. 

DMF  Services  are  Transparent  to  the  User.  All  data  to  which  the  user  has  access  are  in  the  ACDs 
of  RDs  known  to  the  DMF.  Some  of  that  data  will  reside  locally  (in  the  same  ensemble  as  tbe  DMF)  and  some 
remotely  (in  an  ensemble  of  another  Component).  Speed  of  access  performance  may  depend  on  whether  the  DMF 
needs  «o  invoke  a  query  or  remote  query  to  satisfy  an  access  request. 

Tbe  DMF  can  be  invoked  by  tbe  SMF,  ALFs,  MSF,  or  IOFs  in  the  same  ensemble,  or  by  a  DMF  in 
another  ensemble  through  a  peer-to-peer  protocol  via  the  TF. 

Implementation  Considerations.  Tbe  implementation  of  a  DMF  will  require  a  data  manipulation 
language  (such  as  Database  Language  SQL  for  data  defined  by  a  relational  model).  Database  management  systems 
may  provide  all  the  services  required  of  a  DMF. 

6.2  Transfer  Facility  (TF) 

Tbe  Transfer  Facility  (TF)  is  the  logical  entity  that  interconnects  all  ensembles.  Whereas  the  other 
facilities  are  considered  to  have  a  separate  manifestation  in  each  ensemble,  tbe  TF  is  considered  to  be  a  facility  that 
has  one  manifestation  only,  but  one  that  extends  across  every  ensemble.  Notwithstanding,  that  manifestation  of  the 
TF  in  every  ensemble  has  a  corresponding  implementation  in  every  Component.  Tbe  logical  interconnectivity 
between  two  ensembles  is  thus  provided  as  a  result  of  tbe  functionality  of  tbe  TF  that  interconnects  the  two 
ensembles.  Tbe  implementation  of  the  TF  in  the  corresponding  Components  will  result  in  functionality  in  each 
Component  together  with  communications  interfaces  and  one  or  more  communications  media  between  those 
interfaces. 

Network  management  includes  management  functions  for  all  layers  of  open  systems  interconnection  (OSD. 
naming  and  addressing,  and  registration  authorities  for  controlling  assignment  of  names  aid  addresses.  Network 
management  will  be  addressed  in  part  by  work  being  conducted  in  ISO  aid  CCITT  (e.g.,  ISO  7498-3,  Naming  and 
Addressing,  and  ISO  7498-4,  Management  Framework).  Those  aspects  required  to  ensure  interoperability  will  be 
addressed  by  the  standards  to  be  adopted  for  the  arc'  i lecture.  These  include  configuration  management  and  fault 
management  as  well  as  common  management  information  services  and  protocols. 
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6.3  Service  Control  Facility  (SCF) 

The  Service  Control  Facility  (SCF)  is  the  logical  entity  that  binds  together  all  the  facilities  in  an  ensemble. 
The  services  of  the  SCF'  arc  expected  to  be  provided  by  the  underlying  operating  system  of  the  implementation. 
There  is  no  concept  of  peer  interactions  between  SCFs. 

A  facility  will  be  explicitly  aware  of  the  services  that  it  requires  of  another  facility  and  will  invoke  a  request 
for  such  a  service  via  the  SCI-'.  The  only  standard  identified  to  date  that  applies  to  the  SCF  is  the  Portable  Operating 
System  Interface  for  Computer  Environments  (POSIX)  (IEEE  P1003). 

6.4  System  Management  Facility  (SMF) 

The  SMF  is  a  logical  entity  intended  to  provide  functionality  supplementary  to  the  management  services  of 
the  DMF  and  TF  for  control  of  parts  or  all  of  a  system.  However,  to  date,  no  specific  functionality  has  been 
identified  for  SMF  that  is  not  provided  by  DMF  and  TF.  No  standards,  therefore,  have  been  identified  for  the  SMF. 
Ihus,  the  system  management  aspects  of  Basic  Interoperability  appear  to  be  satisfied  by  exchanging  system 
management  data  and  using  management  services  of  DMF  and  TF. 

7.  Application-Level  Facilities 

An  application-level  facility  (ALF)  is  a  logical  entity  that  provides  services  to  support  the  functionality  of 
part  or  all  of  one  or  more  Key  Tasks.  An  ALF  may  be  very  general  purpose,  such  as  a  word  processor,  or  may  be 
unique  to  a  single  Key  Task,  such  as  a  battle  management  decision  aid.  The  entities  with  which  a  user  interacts, 
whether  directly  or  indirectly,  arc  ALFs.  Some  ALFs  are  therefore  likely  to  contain  particular  procedures  and 
doctrinal  aspects  embedded  within  them  that  will  be  specific  to  an  individual  nation.  These  may  therefore  be  mote 
difficult  to  agree  to  on  a  multinational  basis  and  hence  will  tend,  at  least  initially,  to  be  Nation-specific. 

8 .  Other  Facilities 

This  section  describes  two  facilities  that  provide  additional  capabilities  over  those  provided  by  the  four  Basic 
Facilities  and  the  ALFs.  They  have  been  specifically  identified  because  they  act  as  interfaces  between  the  architecture 
on  the  one  hand  and  users  or  nonconformanl  systems  on  the  other  hand.  Neither  of  these  facilities  are  required  for 
conformancy,  but  their  use  would  provide  the  potential  for  cost  savings. 

8.1  MMI  Service  Facility  (MSF) 

Users  require  means  to  interact  with  an  ADP  system.  Within  the  architecture,  the  MSF  has  been  identified 
as  providing  a  standard  set  of  user  services  as  the  interface  between  a  user  and  the  other  facilities  within  the 
ensemble.  This  could  be  provided  separately  for  every  ALF,  but  providing  a  unique  interface  for  each  ALF  would 
limit  flexibility  and  the  potential  for  cost  savings.  MSF  will  provide  services  both  to  users,  so  that  they  can  call  on 
the  services  of  appropriate  facilities,  and  also  to  those  facilities  so  they  can  display  information  to  users  and  solicit 
responses  or  input 

8.2  Non-ATCCIS  Input/Output  Facilities  (lOFs) 

An  IOF  is  a  logical  entity  for  providing  the  services  for  interface  between  conformant  systems  and 
nonconformanl  systems.  Because  there  will  be  several  different  nonconformanl  systems  for  which  interfaces  will  be 
required,  there  will  be  a  family  of  IOF  types  rather  than  a  single  one.  Within  an  ensemble  there  can  be  one  of  each 
type  of  IOF. 

One  part  of  the  interface  between  a  conformant  system  and  a  nonconformanl  system  is  not  designed  in 
accordance  with  standards  of  the  architecture.  This  interface  will  be  an  IOF  providing  the  necessary  services  to  pass 
data  out  to  nonconformanl  systems  and  to  receive  data  from  those  systems. 

Standards  for  IOFs  will  be  defined  as  required  for  each  type  of  nonconformanl  system  and  will  include  both 
data  management  and  data  transfer  standards.  Examples  arc  STANAG  5500  messages. 
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THE  USE  OF  INTEROPERABILITY  PARAMETERS  TO  ENSURE  STANDARDS 

COVERAGE 

1.  INTEROPERABILITY  PARAMETER  METHODOLOGY 

1 . 1  General 

This  section  describes  a  methodology  for  ensuring  adequate  standards  coverage  through  detailed  analysis  of 
the  parameters  that  are  required  to  achieve  interoperability  against  specific  standards  that  control  these  parameters. 

1.2  Description  of  the  Methodology 

An  Interoperability  Parameter  (IP)  is  a  system  or  design  parameter  whose  control  is  required  to  achieve 
interoperability.  These  parameters  are  identified  in  system  specifications,  interface  control  documents,  and  other 
requirements  documents  prior  to  or  very  early  in  the  system  development  process.  In  many  cases,  the 
interoperability  parameters  are  controlled  through  the  specification  of  a  range  of  standards.  The  assembled  parameters 
act  as  a  checklist  for  interoperability,  since  each  IP  must  be  controlled  by  a  suitable  standard.  The  purpose  of  an 
analysis  mdng  IPs  is  to  recognize  and  examine  all  relevant  quantities  and  characteristics  in  a  direct  manner,  instead  of 
momming  that  existing  nr  draft  standards  will  provide  adequate  coverage  of  the  quantities. 

One  of  the  underlying  principles  for  the  ATCCIS  concept  is  that  specifying  standards  is  essential  to 
ensuring  interoperability.  However,  it  cannot  be  emphasized  too  strongly  that  specifying  standards  alone  will  not 
guarantee  interoperability.  Indeed,  every  standard  has  a  number  of  design  parameters  or  IPs  whose  values  may  need 
to  be  fixed  in  the  design  phase  of  implementation.  To  ensure  interoperability,  each  of  these  IPs  must  also  be 
specified  and  controlled.  Some  IPs  are  very  general  and  may  be  used  to  specify  a  class  of  options  or  mode  of 
operation.  Other  IPs  may  be  very  detailed,  such  as  restrictions  on  timing,  format  size,  or  bandwidth. 

IPs  can  be  identified  and  appropriately  controlled  in  any  stage  of  system  development,  from  initial  concepts 
and  requirements  to  detailed  design  and  as-built  specifications.  Parameters  may  simply  be  the  identity  of  governing 
specifications  (e.g.,  standards)  far  interface  or  other  requirements.  They  could  be  the  identity  of  options  or 
specification  of  limits  on  performance  requirements.  They  could  include  lists  of  services  or  routines  that  are 
or  that  are  denied  for  use.  IPs  may  include  logical  or  physical  layouts  that  show  such  elements  as 
sequences,  relationships,  interconnections,  and  logical  block  diagrams.  IPs  may  include  waveforms.  They  may 
include  operating  procedures,  such  as  dial  settings.  In  short,  IPs  include  any  information  item  that  needs  to  be 
controlled  at  any  stage  of  development  to  ensure  interoperability. 

Because  each  standard  is  a  reflection  of  the  degree  to  which  agreement  can  be  reached  in  a  service  area,  many 
important  attributes  (i.e„  IPs)  are  often  left  unspecified  or  unaddressed.  As  agreements  are  reached  over  time,  the 
standards  will  improve  by  addressing  more  funoionality  and  harmonizing  conflicting  approaches.  In  cases  where 
standards  identify  extensions  aid  other  types  of  options,  great  care  must  be  taken  in  standards  specification  and  IP 
control  to  ensure  that,  whenever  an  extension  or  option  is  permitted,  every  implementation  of  the  related  service  also 
supports  this  extension  or  option.  This  principle  is  especially  important  in  achieving  not  only  interoperability  but 
also  portability  of  applications  from  one  implementation  or  environment  to  another,  such  as  is  needed  when 
operating  systems,  data  management  systems,  interface  packages,  and  hardware  are  upgraded. 

1.3  Examples  of  Interoperability  Parameters 

This  section  provides  a  brief  introduction  to  interoperability  parameters  by  examining  portions  of  three  sets 
of  standards: 

•  Physical  standards  for  23-pin  connectors  (i.e.,  EIA  RS-232D  interface) 

•  Electrical  characteristics  of  digital  interface  circuits  (i.e„  EIA  RS-423A  retd  QSTAG  394) 

•  Transmission  characteristics  for  single  channel  radio  (i.e.,  STANAG  4202). 

1.3.1  Physical  Standards  for  25-pin  Connectors 

Table  B-l  identifies  a  number  of  electrical  and  mechanical  interoperability  parameters  controlled  by 
EIA  RS-232D  for  23-pin  connectors.  The  first  two  columns  provide  the  definition  of  the  interoperability  parameter, 
the  values  specified  in  the  standard,  if  any,  are  given  in  the  third  column. 
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Tabic  B-1.  Example  Intaroparability  Parameters  Baaed  on 
Characteristics  of  Unbalanced  Load  Digital  Interface  Circuits, 
25-Pin  Interface  Connectors 


Description  of  Interoperability  Parameter 

Example  Value  of  IP 

EXAMPLE  ELECTRICAL  CHARACTERISTICS: 

Undefined  condition 

Minimum  voltage 

Maximum  vcf age 

-3  volts 
+3  volts 

Marking  condition 
(binary  ONE) 

Interface  Voltage  Maximum 

•3  volts 

Spacing  condition 
(binary  ZERO) 

Interface  Voltage  Minimum 

+3  volts 

Restriction  on  use  of  hysteresis  techniques  to 
enhance  noise  immunity 

None 

Load  impedance  of  the 
receiver  side 

Minimum  for  applied 
voltage  £  25  volts 

Maximum  for  applied 
voltage  of  3  to  25  volts 

3,000  ohms 

7,000  ohms 

Effective  shunt 
capacitance  of  receiver 

Maximum 

2,500  picofarads 

|  EXAMPLE  MECHANICAL  CHARACTERISTICS: 

Number  of  Pins 

25 

Cable  length 

Maximum 

Not  specified 

Connector  length 
(male  contacts, 
female  shell) 

Minimum 

Maximum 

38.84  mm 

39.09  mm 

Connector  width 
(male  contacts, 
female  shell) 

Minimum 

Maximum 

8.23  mm 

8.48  mm 

Contact  spacing. 

Pin  #1 

Longitudinal  offset 

Lateral  offset 

♦16.56  mm 
♦1.42  mm 

Contact  spacing. 

Pin  #2 

Longitudinal  offset 

Lateral  offset 

+15.19  mm 
-1.42  mm 

Contact  spacing. 

Pin  #25 

Longitudinal  offset 

Lateral  offset 

-16.56  mm 
+1.42  mm 
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Tab  la  B-1.  (Continuad) 


1  Description  of  Interoperability  Parameter 

Example  Value  of  IP 

Pin  dameter 

Minimum 

0.96  mm 

Maximum 

1.06  mm 

Pin  length,  overall 

Minimum 

9.77  mm 

with  mounting 

Maximum 

10.03  mm 

Pin  mounting  length 

Minimum 

1.57  mm 

Maximum 

1.76  mm 

Female  contact  length, 

Minimum 

9.27  mm 

overal  with  mounting 

Maximum 

9.63  mm 

Female  contact  socket 

Minimum 

7.37  mm 

depth 

Maximum 

7.37  mm 

Pin  assignment 

Pin  #1 

Shield 

Pin  #2 

Transmitted  Data  (BA) 

Pin  #5 

Clear  to  Send  (CA) 

Pin  *25 

Test  Mode  (TM) 

Female  contact  socket 

Minimum 

7.37  mm 

Maximum 

7.37  mm 

Sourcaa: 

(1)  DIS  2110,  25-Pin  DTE/DCE  Interface  Connector  and  Pin  Assignments  (related  to 
ElA  RS-232C),  November  1965. 

(2)  ElA  RS-232D,  Interface  Between  Data  Terminal  Equipment  and  Data  Grain-Terminating  Equipment 
Employing  Serial  Binary  Data  Interchange,  1986. 

(3)  ElA  RS-449,  General  Purpose  37-Position  and  9-PosUon  Interface  for  Data  Terminal  Equipment  and 
Data  Circuit-Terminating  Equipment  Employing  Serial  Binary  Data  Interchange,  November  1 97 7. 

(4)  ElA  Industrial  Electronics  Bulletin  1EB-12,  Application  Notes  on  Interconnection  Between  Interface 
CkvuitM  Using  RS-449  and  RS-232C,  November  1977. 
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1.3.2  Electrical  Characteristics  of  Digital  Interface  Circuits 

Table  B-2  identifies  interoperability  parameters  of  digital  interface  circuits  that  are  controlled  by 
QSTAti  594.  These  arc  all  electrical  characteristics. 


Table  B-2.  Example  Interoperability  Parameters  Baaed  on 
Electrical  Characteristics  of  Unbalanced  Load  Digital  Interface  Circuits 


S  Description  of  Interoperability  Parameter 

Example  Value  of  IP 

Open  circuit  voltage. 

Minimum  magnitude 

4  volts 

generator 

Maximum  magnitude 

6  volts 

Test  termination 

450  ohm  ±1%  test  load  min 

90%  magnitude  of  open 

voltage,  generator 

circuit  voltage 

Short  circuit  current, 
generator 

Maximum  magnitude 

150  mA 

Output  leakage  current. 

Maximum  magnitude  with 

100  pA 

current,  generator 

applied  voltage  from  -6  V  to 
+6  V 

Output  signal 

Minimum  magnitude 

3.6  volts 

waveform  voltage 

Maximum  magnitude 

6  volts 

Variance  between  transitions 

Within  10%  steady  state 

Output  signal 

Rise  time  to  90%  steady  state 

waveshaping 

at  maximum  signaling  rate 

Minimum 

0.1  unit  interval 

Maximum 

Rise  time  to  90%  steady  state 
at  signaling  rates  below  1  kb/s 

0.3  unit  interval 

Minimum 

100  psec 

Maximum 

300  usee 

High  impedance  state 

Requirement 

Optional 

Output  voltage  at  high  imped 
and  450  ohm  ±1  %  test  load 

Zero  (nominal) 

Wire  or  cable 

Characteristics 

Not  addressed 

Signaling  rates 

Not  specified 

Total  load 

Resistance  minimum 

400  ohms 

Required  differential  input 
voltage  to  achieve  intended 
binary  state 

200  mV 

Fail  safe 

Requirement 

Optional 

Sources: 

(1)  QSTAG  594.  Electrical  Characteristics  of  Digital  Interface  Circuits,  25  March  1981  (adopts  MIL-STD- 
188-114). 

(2)  MIL-STD-1 88-1 1 4A,  Electrical  Characteristics  of  Digital  Interface  Circuits, 
30  September  1985  (Revision  of  MIL-STD-1 88-1 14  dated  24  March  1976). 

(3)  ITU-TS  V.10/X.26,  Electrical  Characteristics  for  Unbalanced  Double-Current  Interchange  Circuits  for 
General  Use  With  Integrated  Circuit  Equipment  in  the  Field  of  Data  Communications,  1985  (related  to  EIA  RS- 
423A,  which  is  compatible  with  MIL-STD-1 88-1 14A). 

(4)  EIA  RS-423A,  Electrical  Characteristics  of  Unbalanced  Voltage  Digital  Interface  Circuits,  December 
1978. 
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1.3.3  Transmission  Characteristics  for  Single  Channel  Radio 

Table  B-3  presents  a  nearly  complete  summary  of  the  interoperability  parameters  controlled  by 
STANAG  4202  for  single  channel  radios.  This  standard  is  in  use  in  NATO  as  the  basis  of  interoperability  for  digital 
data  transmission  on  combat  net  radio. 


Table  B-3.  Example  Interoperability  Parameters  Based  on 
Single  Channel  Radio  Standards  (STANAG  4202) 


1  Description  of  Interoperability  Parameter 

Example  Value  of  IP 

Frequency  band 

Minimum  frequency 

Maximum  frequency 

Channel  spacing 

Not  specified 

Not  specified 

Not  specified 

Transmission  rates  (1) 

Preferred  rate 

Other  required  rates 

600  b/s 

300, 1,200  (and  150  for  HR 

Modulation 

Type 

FSK 

Data 

Character  coding  type 

NATO  7-bit 

FSK  modulation 

Mark  (or  1)  frequency 

Space  (or  0)  frequency 

Audio  tone  frequency 
accuracy,  transmit 

Receiver  accuracy 

1575  Hz 

2425  Hz 

±  5  Hz  (±  1  Hz  desired) 

±20  Hz 

FSK  transition 
between  marie  &  space 

Maximum  phase 
discontinuity 

5degrees 

FSK  timing 

Minimum  clock  accuracy  for 
synchronous  data 

±  1  partin  10**5 

Keytime  delay 

Required 

Options 

Modulation  applied 

0  53333  2.026676  sec 

Multiples  of  0.10667  sec  (2) 
Reversals  ending  in  a  zero 

Bit  synchronization 

Length 

33  bits 

Modulation 

Reversals  emting  in  a  *1* 

Character 

Length 

63  bits 

synchronization 

preamble 

Modulation 

Pseudo-random  sequence 
generated  by  a  (6,1)  shift  register 
starting  with  *111111* 

Message  preparation 
for  transmission 

Initial  character 

Message  structure 

Message  padding 

*Sr  or  *NUL*  (clear, 
respectively,  encrypted  text 
follows) 

7-bit  bytes 

Up  to  6*1*  bits 

Cyctic  redundancy 

CRCtype 

Polynomial 

check  (applied  to  the 

Generator  (mod  2) 

x**16+x**12+x**5+1 

entire  input  message) 

Conversion  to  8-bit  byte 

Size  of  check 

CRC  packing 

0  in  most  significant  bit 

Three  7-bit  bytes 

NATO  7-bit  end-of-text  chars 
as  required  (up  to  1 5)  (3) 

Envelope  termination 

Size 

Four  7-bit  characters 

NATO  7-bit  end-of-text  chars 

Notes: 

(1)  STANAG  4202  (Appendix  B)  provides  guidelines  (or  interim  use  of  16,000  b/s  channels  that  are  not 

#  shown  in  Oils  table. 

(2)  0. 1 0667  sec  is  the  time  to  send  1 28  bits  atl  ,200  b/s  or  64  bits  at  600  b/s. 

(3)  The  minimum  massage  is  16x7  or  112  bits  and  requires  0.19  sec  at  600  b/s. 
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Table  B-3.  (Continued) 


i  Description  of  Interoperability  Parameter 

Example  Value  of  IP 

Error  detection  and 

ED&C  type 

Hamming  (12,7),  produces 

correction  coding 

1 2-bit  coding  for  every 

(applied  to  7-bit  bytes) 

7-bit  byte 

Time  dispersal  coding 

TDC  interleaving  array  size 

16x12,  with  sixteen  12-bit 

Hamming  codes 

Errors 

Number  of  acceptable 

None  (stop  processing  and 

but  uncorrectable  errors 

send  no  NACK) 

Source:  STANAG  4202  EL  (Edition  2).  Transmission  Envelope  Characteristics  for  High  Reliability  Data 
Exchange  Between  Land  Tactical  Data  Processing  Equipment  Over  Single  Channel  Radio  Links,  Military  Agency 
for  Standardization,  NATO,  25  May  1988. 


1.3.3  Interoperability  Parameters  for  X.25  Packet  Switching 

Table  B-4  provides  the  interoperability  parameters  for  the  Implementor's  Agreements  on  the  X.2S 
packet  switching  protocol  as  defined  in  the  1989  NIST  Workshop  stable  agreements  that  apply  to  U.S.  GOSIP 
Version  1.0.1  The  NIST  Workshop  understands  that  agreement  to  these  interoperability  parameters  will  ensure 
interoperability  of  implementations  of  the  X.2S  protocols. ^ 

2.  USING  INTEROPERABILITY  PARAMETERS  TO  CHARACTERIZE  MILITARY 
FEATURES  IN  OSI-RELATED  TACTICAL  STANDARDS 

This  section  is  intended  to  be  expanded  to  demonstrate  the  use  of  interoperability  parameters  to  describe  bow 
some  fielded  tactical  data  systems  are  implementing  military  versions  of  OS1  standards  to  achieve  interoperability. 
The  descriptions  here  extend  the  tables  provided  in  Chapter  18  to  describe  the  Quadrilateral  Interoperability  Program 
and  STAMINA.  Examples  will  also  be  taken  from  Appendix  C,  National  Initiatives  for  Military  Use  of  OSI 
Standards. 


1  Stable  Implementation  Agreements  for  Open  Systems  Interconnection  Protocols,  Version  2,  Edition  1,  NIST 
Special  Publication  500-16,  National  Institute  of  Standards  and  Technology,  December  1988,  UNCLASSIFIED. 

2  Private  communication  with  Director.  Systems  and  Network  Architecture  Division,  NIST,  25  May  1989. 
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Table  B-4.  Interoperability  Parametera  tor  X.2S  Packet  Switching 


ISO  Layer* 
Function 


Standard* 

Cited 


NoCm  on  IntoroponbWtv 
Paramatara 


General 


CCITTX25 


Defines  procoduroe  required  to  describe  the  DTE  aide 
of  a  CTE/DCE  interlace  for  systems  attached  to  subnetworks 


providing  an  )C25  interface  ahaM  be  as  defined  in  ISO  7776 
and  ISO  8206  as  indcated  below. 


•  These  procedures  shall  also  apply  to  a  DTE  operating  on  a 
DTE/DTE  interface. 


3 


Network  Layer 


ISO  8208 
(X.25  PLP) 


The  elements  of  ISO  8208  applicable  for  use  depend  on  the 
OSI  role  of  ISO  8208  (f.e.,  provision  of  CONS,  support  of 
CLNP): 

a.  When  ISO  8208  is  used  to  support  CONS,  the  optional 
user  facilities  in  Section  5.1  of  ISO  8878  shall  be  supported. 

b.  When  ISO  8208  is  used  to  support  CLNP  (vrtwn 
providing  the  CLNS),  Permanent  Virtual  Circuit  may  be  used. 
Virtual  Cal  Service  is  requited. 


•  Any  mutually  agreed  window  and  packet  size  may  be  used; 
however,  al  DTE*  must  be  capable  of  supporting  a  window 
size  of  2.  a  packet  size  of  128  octets,  and  a  sequence  number 
modulus  of  8. 


2 


Data  Link  Layer 


ISO  7776 
(HDLC 
Procedures- 
X.25  LAPS) 


The  Basic  RPOA  Selection  Facility  shall  be  implemented  and 
Its  use  or  non-use  selectable  on  a  per  virtual  cal  basis.  (1) 
The  address  assignments  are: 

DTE -A  (>11000000  binary) 

DCE*B  (>10000000  binary). 

On  a  DTEATTE  interface,  one  of  the  DTEs,  by  a  prior 
agreement  ahal  use  the  DCE  address. 

The  modulus  Sal  be  8. 


•  A  window  size  (k)  of  7  shall  be  stjjpotted.  In  addHon,  other 
window  sizes  may  also  be  supported. 

•  The  Mutt!  Ink  Procedures  are  excluded. 


Notes: 


1.  Agreement  on  the  Basic  RPOA  Selection  Faclity  parameter  is  an  ongoing,  not  a  stable, 
implementation  agreement 
References: 

1.  Stable  implementation  Agreements  tor  Optn  Systems  Interconnection  Protocols.  Version  1, 
Edition  1,  NIST.  December  1988. 

2.  Ongoing  Implementation  Agreements  for  Open  Syttmt  intorcomoction  Protocols.  Continuing 
Agnmntt,  NISTIR  88-3824-2,  NIST.  February  1989. 


Appendix  B 


B-7 

UNCLASSIFIED 


Use  of  Interoperability  Parameters 


UNCLASSIFIED 


Appendix  B 


(This  page  intentionally  left  blank) 


B-8  Use  of  Interoperability  Parameters 

UNCLASSIFIED 


UNCLASSIFIED 


APPENDIX  C 

NATIONAL  INITIATIVES  FOR  MILITARY  USE  OF 
OSI  STANDARDS 


UNCLASSIFIED 


UNCLASSIFIED 


NATIONAL  INITIATIVES  FOR  MILITARY  USE  OF 
OSI  STANDARDS1 

1.  INTRODUCTION 

This  appendix  identifies  profiles  being  used  ia  national  initiatives  that  make  or  plan  lo  make  significant  me 
of  OSI  atandmds  in  military  applications.  The  purpose  it  10  provide  detailed  information  on  prafleslhtt  am  pined 
for  evohriag  tactical  CCISs  m  the  nations.  Additional  contributions  to  this  appendix  (at  well  at  other  parts  of  ttus 
document)  are  wdocmc. 

NATO  work  on  OSI  is  diacussed  in  Chapter  17.  M*or  bilateral  and  multilateral  NATO  initiatives  are 
discussed  ia  Chapter  18;  these  include  the  Quadrilateral  Interoperability  Program  and  STAMINA  Many  national 
initiatives  are  diacutaed  in  Chapter  19. 


2.  CCIS  PROFILES  FOR  INTEROPERABILITY 

2.1  Details  o t  Standards  for  French  National  Initiatives  tor  Enhanced 
Interoperability 

The  Army  win  use  standardized  products  baaed  on  the  following  standards: 

•  Programming  language:  LTR3  (Language  Temps  Red),  Ada,  C 
Database:  Relational  datahair  management  systems.  SQL 

•  Operating  System:  UNIX 

•  Development  methods:  Baaed  on  tbt  Preach  mtitey  standard  GAM-T-17. 

2.2  Overview  at  Data  Conunnaicationa  Car  US  Army's  ATCCS 

Die  Army  Tactical  Command  Control  System  (ATCCS)  architecture  is  diaentaed  in  Chapter  19  (Section 
19.1.6).  This  section  highlights  the  organization  of  data  conammiratiraie  services  ptaaaed  for  ATCCS. 

Figure  C-l  identifies  the  protocol  stacks  specified  ia  the  Initial  Baariinr,  and  Figure  C-2  identifies  the 
protocols  for  the  next  stage  [termed  "Effcctivity  Al.r  and  planned  for  the  Follow-On  Test  and  Evaluation  (FOT&E) 
milestones]  for  ATCCS.* 

•  The  local  area  network  (LAN)  interface  is  defined  by  TCMP.  IEEE  8GL2  (LLC  1)  and  IEEE 
802.3  (CSMA/CD). 

•  The  MSE  Packet  Network  (MPN)  uses  TCP/IP,  ITU-TS  X.25,  HDLC  LAPS  (ISO  7776)  and 
four-wire  oonditioned  diphase.  (CDP)  or  fiber-optic  Thin  LAN. 

•  US  DoD  Internet  protocols  used  over  TCMP  are  FUe  Transfer  Protocol  (FTP).  Simple  Mail 
Transfer  Protocol  (SMTP),  Simple  Network  Management  Protocol  (SNMP),  and  TELENET. 
The  standards  for  thoac  protocola  are  hated  in  Appendix  H. 

•  The  UDP  it  provided  to  permit  stacks  over  the  Connectionless  Network  Protocol  (CLNP)  to  use 
the  MPN  and  LAN  communications. 

•  Combat  Net  Radio  (CNR)  interfhees  are  deft  >d  by  MIL-STD-188  B  and  C,  STANAG  4202,  and 
MIL-STD-188-114A. 

•  The  ATCSS  Common  Hardware/Software  (CHS)  wiB  provide  protocob  at  Layers  2, 3,  and  4  (in 

P«t). 

•  The  MSE  Circuit  Switch  (CS)  htterface  it  through  the  Digital  Noo-Secure  Telephone  (DNVT) 
and  Digital  Secure  Telephone  (DSVT). 

•  Tbe  CHS  provides  physical  Interfaces  to  the  Army  Tactical  Communications  System  (AT ACS). 

1  Effective  date  of  this  Appendbt  is  January  1992. 

2  Cross-nutctional  Area  Interface  Specification  far  ATCCS,  ACCS-A3-400-12,  U.S.  Army  CECOM. 

Appendix  C  C-l  Example  National  Military  Initiatives 

UNCLASSIFIED 


UNCLASSIFIED 


•  Except  for  the  Air  Defense  Functional  Area,  which  also  uses  the  Joint  Tactical  Information 
Distribution  System,  the  ATCCS  users  will  use  only  the  Enhanced  Portion  Location  Reporting 
System  (EPLRS)  portions  of  the  Army  Data  Distribution  System  (ADDS).  EPLRS  uses  a 
CDP  or  MIL-STD-188-U4A  interface.  HDLC  Lap  B.  and  an  ADDS  version  of  X.25.3 

•  An  alternate  MSE  CS  Generic  Gateway  is  provided  by  use  of  the  DNVT/DSVT,  DD  CMP  and 
(Full  Duplex  Message  Protocol  (FDMP).  This  uses  the  MSE  Version  2  Data  Adapter  (V2DA), 
currently  only  in  use  by  the  All  Source  Analysis  System  (AS AS). 

•  Not  shown  is  the  optional  use  of  BLACKER  with  the  MPN  stack. 

•  Not  shown  is  the  Quadrilateral  stack  use  with  MCS  (see  Chapter  18).  This  stack  uses  TP2  and 
a  variant  of  MHS-84. 

•  Not  shown  are  options  for  LAN  and  MPN  to  use  an  address  resolution  protocol  (ARP)  and  a 
reverse  address  resolution  protocol  (RARP). 


PROTOCOL  SELECTOR 


SMTP 


TCP 


MHS  X.400 


RTSE  ISO  9066 


ACSE  ISO  8650 


PRESENTATION  ISO  8823 


SESSION  ISO  8327 


CONNECTIONLESS 
TRANSPORT  SO  (M2 


CONNECTIONL  OMEMTED  TRANS¬ 

PORT (TP-2,  TP-4)  aO  (0TJ 


CLNP  ISO  8473 


CH2 


IP 


LLC  1  (802.2) 


IEEE  802.3 


LAN  &  MPN 


1 

MCS 

MCS 

MCS 

PROTOCOLS 

PROTOCOLS 

PROTOCOLS 

1 

MIL-STD-1M8.C 

DNVT/DSVT 

SW/HW 

CNR 

MSECS 

ATACS 

Source:  Cross-Functional  Area  Interface  Specification  for  ATCCS, 

ACCS- A3-400- 1 2.  U  S.  Army  CECOM 

Figure  C-1.  ATCCS  Inter-BFA  Communications  Protocols  (Initial  Baseline) 


3  ADDS  X.2S  and  MPN  X.25  arc  not  identical  and  not  reported  to  be  interoperable. 
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Mm  LAMS  MM  am  MKCS  ATACa  ADOS  MKCS  Via  VMM 

Somk  Croas-Fuactkmal  Ana  Interface  Specification  for  ATCCS,  ACCS-A3-400-12,  U.S.  Amy  CEOOM. 


Figure  C-2.  ATCCS  Intsr-BFA  Communications  Pratoeol*  (Eff activity) 


2.3  Advanced  Field  Artillery  Tactical  Data  Systems  (AFATDS)4 

AFATDS  is  die  Fire  Support  (FS)  functional  area  control  system  of  the  Army  Command  and  Control 
System  (ACCS)  and  Marine  Tactical  Command  and  Control  System  (MTACCS). 


2.3.1  System  Overview 

AFATDS  will  provide  an  automated  command  control,  and  coardmabon  system  which  satisfies  tbe 
Fite  Support  requirements  generated  by  AirLand  Battle  doctrine.  AFATDS  equipment  will  be  employed  worldwide 
in  support  of  tbe  U3.  Army  Fire  Support  Battlefield  Functional  Area  (BFA)  and  Marine  Corps  fire  support 
requirements.  AFATDS  software  development  will  be  accomplished  In  successive  versions,  each  Implementing 
additional  functionality  and  interfaces,  beginning  with  Version  1;  Versions  2  and  3  will  expand  AFATDS 
functionality  through  development  on  its  predecessor  version. 

AFATDS  Version  1  will  include  component  elements  provided  by  the  Army  Tactical  Command 
and  Control  System  Common  Hardware  and  Software  (ATCCS  CHS)  program  and  the  Standard  Integrated  Command 
Post  System  (SICPS)  program. 

AFATDS  is  a  multi-service  United  States  Army/United  States  Marine  Corps  (USAAJSMC) 
automated  command  and  control  (C2)  system  for  Fire  Support  Operations  (FSOF).  Tbe  initial  fielding  of  AFATDS 
will  be  Version  1  (VI).  which  will  be  capable  of  managing  field  artillery  (FA),  air  fire  support  (AFSVMarine  Air 
naval  gunfire  (NGF)  and  mortar  attach  systems  at  all  echelons  from  corps  to  platoon  level.  AFATDS  will  provide 
tbe  capabilities  to  process,  analyze,  and  exchange  combat  information  within  tbe  AFATDS  architecture  and  with 
otter  Army  BFA  systems,  selected  NATO  systems,  and  Marine  Tactical  Command  and  Control  System  (MTACCS) 
component  systems  in  Marine  Amph&ious  Air-Ground  Task  Forces  (MAGTFs). 

AFATDS  will  be  a  system  of  mobile,  dispersed,  multi-functional  nodes  providing  automated 
planning  and  execution  capabilities  to  fire  support  operational  facilities  (OPFACs)  and  Independent  User  Centers 
(IUCs).  OPFACs  will  operate  at  Fire  Support  Elements  (FSEs)  of  tbe  supported  maneuver  force,  field  artillery 
command  pores,  and  other  FA  elements  throughout  tbe  command  structure.  IUCs  are  remote  terminals  that  allow 
rnramanrtrn  and  selected  fire  support  persoood  id  monitor  fire  support  operations  and  issue  guidance  and  directives 
from  widely  dispersed  battlefield  locations.  The  operational  context  for  AFATDS  is  given  for  tbe  Army  in  Figure 
C-3  and  for  the  Marine  Corps  in  Figure  C-4. 


4  This  lection  is  based  on  tbe  following  contribution:  AFATDS  Data  Communications.  Draft,  Henry  Saphrow, 
OPM  AFATDS,  U.S.  Army  CECOM,  January  1992,  UNCLASSIFIED. 
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The  AFATDS  VI  contract  was  awarded  in  May  1990  with  IOT&E  planned  for  FY94.  AFATDS 
V2  and  V3  are  parallel  efforts  starting  in  FY92  for  Version  2  and  FY94  for  Version  3.  Initial  fielding  of  production 
version  (V2)  is  planned  for  FY95. 

2.3.2  FS  Operational  Capabilities 

AFATDS  OPFAC  capabilities  within  FA  units  will  be  for  the  command,  control,  and  support  of 
organic  and  attached  FA  assets  (i.e.,  target  acquisition  means,  operation  centers,  fire  direction  centers,  weapons,  and 
FA  mission  support  elements).  OPFAC  capabilities  located  with  maneuver  units  (FSE)  will  support  the  advising  of 
the  maneuver  force  commander  on  the  use  of  available  fire  support  assets,  planning  their  employment,  and 
integrating  them  into  the  scheme  of  maneuver.  Marine  Corps  requirements  are  identified  in  the  FI  REFLEX  Required 
Operational  Capability.  Automated  capabilities  will  also  be  provided  within  any  designated  OPFAC  for  performing 
the  fire  support  execution  and  movement  control  functions. 

AFATDS  FS  operational  capabilities  are  contained  in  five  general  operational  need  categories. 
These  categories  are  the  following: 

a.  Fire  Support  Planning  (FSP)  -  provides  the  overall  planning  capabilities  for  integration  of  field 
artillery,  air  fire  support,  naval  gunfire,  and  mortars  into  the  force's  scheme  of  maneuver. 

b.  Fire  Support  Execution  (FSX)  -  provides  automated  support  for  target  processing,  attack 
systems  analysis,  and  tactical  fire  direction. 

c.  Movement  Control  (MC)  -  provides  for  the  movement  control  of  field  artillery  units,  prepares 
movement  requests,  coordinates  those  requests  with  the  appropriate  farce  level  headquarters,  and 
maintains  movement  data. 

d  Field  Artillery  Mission  Support  (FAMS)  -  provides  for  logistical  support  for  the  field  artillery 
system. 

e.  Field  Artillery  Fire  Direction  Operations  (FAFDOPS)  -  maintains  the  current  status  of  fire 
missions,  fire  support  and  field  artillery  units. 

2.3.3  Interoperability  Capabilities 

AFATDS  will  interoperate  with  existing  tactical  systems  in  order  to  serve  as  an  integral  element 
in  the  overall  command  and  control  structure.  These  systems  consist  of  those  FS  systems  directly  engaged  in 
execution  of  the  Field  Artillery  mission  and  those  other  control  systems  which  form  the  A7CCS.  The  following 
list  summarizes  the  principal  Version  1  AFATDS  interfaces. 

a  FS  Sensor  Systems  (e.g..  Fire  finder,  DMD,  DCT,  ATHS) 

b.  FS  Weapons  Control  Systems  (e.g„  BCS,  MBC,  FDS) 

c.  Adjacent  Systems  [e.g..  TACFIRE,  ADLER,  LTACFIRE,  AFATDS  (USMC)] 

d  Maneuver  Control  System  (MCS)  •  BFA  and  Force  Level  Control  (FLC) 

e.  All  Source  Analysis  System  TOC  Support  Element  (ASAS  TSE)  •  Intelligence/  Electronic 
Warfare  (I/EW)  Data 

f.  Forward  Area  Air  Defense  Command  and  Control  (FAAD  C2)  •  Air  Defense  Support 

g .  Met  Data  System  -  Technical  fire  control  meteorological  data 

h.  AFATDS  Operators. 
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Figure  C-3.  AFATOS  (US  Army)  Operational  Context 


Figure  C-4.  AFATOS  (USMC)  Operational  Context 

Note:  AFATDS  will  be  a  system  of  mobile,  dispersed,  multi-functional  nodes  providing 
automated /donning  and  execution  capabilities  to  fire  support  operational  facilities. 
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2.3.4  AFATDS  Communication  Requirement 

AFATDS  primary  method  of  communication  is  via  the  Combat  Net  Radio  (CNR).  Other 
communication  capabilities  includes  Area  Common  User  System  (TR1-TAC,  Mobile  Subscriber  Equipment,  and 
Unit  Level  Switch),  Army  Data  Distribution  System  (ADDS)  and  Position  Location  and  Reporting  System  (PLRS), 
field  wire  (2W,  4W)  and  local  area  network  (IEEE-802.3).  AFATDS  communication  requirements  include: 
operation  on  the  move,  continuity  of  operations  (CONOPS),  alternate  net  routing,  communication  channel 
reconfigurability  while  system  is  operational,  operation  with  four  programmable  communication  channels,  receive, 
transmit,  and  process  over  2,000  messages  per  hour  over  secure  link.  Additional  requirements  include:  detection 
reduction  by  the  enemy,  multiple  destination  communication,  network  loading  and  balancing,  and  automatic  relays. 
To  meet  heavy  traffic  demand  and  reliable  communication  over  the  CNR,  AFATDS  design  implemented  a 
communications  architecture  described  in  the  next  section. 

2.3.5  AFATDS  Communications  Architecture 

Figures  C-5  and  C-6  illustrates  the  organization  of  communications  protocols  used  between  FSWs  with 
regard  to  the  ISO  OSI  Basic  Reference  Model,  ISO  7498.  Applications  processes  utilized  one  or  more  Application 
Service  Elements  (ASEs)  which  embody  the  functions  of  the  ISO/OSI  model's  application,  presentation,  and  session 
layers.  Examples  of  ASEs  are  file  transfer,  message  exchange,  and  X-Windows.  ASEs  rely  on  the  data  transfer 
services  of  transport  and  lower  layer  protocols  that  are  common  to  all  Fire  Support  Workstations  (FSWs),  to 
facilitate  their  peer  relationships. 
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Figure  C-5.  Organization  of  Communicationa  Protocola  in  AFATDS 
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Figure  C-6.  AFATDS  Protocol  Stacks 


Physical  Layer.  Connections  to  the  following  devices  are  provided  in  the  Physical  Layer. 

•  UHF:  SINCGARS  Radio.  VRC-12,  AN/PRC-77,  AN/PRC-68 

•  HF:  AN/PRC-104,  AN/GLC-213,  AN/GRC-193,  AN/GRC-106 

•  MSE:  DNVT,  DSVT,  EPLRS,  PLRS,  and  ULS. 

Data  Link  Layer.  The  data  link  is  based  upon  Joint  VMF-TIDP-TE  Vol  IV.  Presently  this 
standard  only  supports  Type  I  services.  AFATDS/VMF  CPS  (AFATDS  Variable  Message  Format 
Communications  Protocol  Standard)  supports  both  Type  I  and  Type  II  services.  Type  I  is  based  on  MTS  Broadcast 
standard  with  enhancements  agreed  by  the  Joint  Message  Standard  Working  Group.  The  Type  D  services  are  based  on 
IEEE  802.2  and  HDLC  Lap  B  protocols  with  some  enhancements  for  Combat  Net  Radio  (CNR).  The  following 
enhancements  are  part  of  AFATDS/VMF  CPS: 

•  Multi-Frame  Transmissions 

•  Uncoupled  Acknowledgements 

•  Use  of  Poll/Final  (P/F)  Bit 

•  Implementation  of  "Windowing"  for  Multi-Frame  Transmissions 

•  Use  of  Sequence  numbers  for  State  Variables 

•  Selective  Rejection  Balanced  Mode  Extended  (S  ABME)  Framr 

•  Frame  Reject  (FRMR)  Frame 
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•  Reset  (RSET)  Frame 

•  Disconnect  (DISC)  Frame. 

Network  Layer.  The  following  network  layer  functions,  which  have  been  derived  from  the 
AFATDS  SSS  requirements  and  CEP  experience,  will  be  supported  for  AFATDS  Version  1. 

•  Interconnection  of  Subnetworks 

•  Addressing 

•  Routing 

•  Error  Control 

•  Flow  Control 

•  Subnetwork  Independent  Convergence  Protocols  (SNICPs) 

•  Subnetwork  Dependent  Convergence  Protocols  (SNDCPs) 

•  Subnetwork  Access  Protocols  (SNAcPs). 

The  network  layer  implementation  for  AFATDS  will  be  based  on  the  DIS  8473  (CLNP),  ISO 
8648,  ISO  8348,  and  ISO  8348/ ADD  1  network  layer  standards.  Due  to  the  unique  FS  requirements  and  the  FS 
operational  environment,  these  standards  will  be  extended  and  modified  as  necessary  for  AFATDS  use.  The 
AFATDS  CLNP-based  internet  protocol  will  be  utilized  as  the  SNICP  over  five  distinct  subnetworks:  the  LAN 
provided  as  pan  of  the  ATCCS  CHS,  tactical  networks  employing  the  VMF-TIDP-TE  data  link  protocol,  tactical 
networks  employing  TACFIRE  protocols.  Enhanced  Position  Location  Reporting  System  (EPLRS)  X.25-based 
networks,  and  Unit  Level  Message  Switch  (ULMS)-based  networks. 

ISO  8473:  Information  processing  systems  -  Data  Communications  •  Protocol  for  providing  the 
connectionless-mode  network  service.  This  is  the  standard  that  AFATDS  has  adopted  in  which  to  base  the 
internetwork  layer.  The  AFATDS  CLNP  functionality  will  use  multiple  SNDCPs  to  access  the  diverse  suite  of 
subnetworks  available  to  it  and  required  of  it  to  gain  the  connectivity  needed  in  the  Army's  limited  channel/bandwidth 
environment.  Currently,  the  inactive  Network  Layer  protocol  subset  will  not  be  used  even  within  an  OPFAC  LAN 
in  order  to  support  the  dynamic  ( re )con figuration  capability  required  in  AFATDS.  The  Non-Segmenting  protocol 
subset  may-or  may  not  be  utilized  awaiting  results  from  yet-to-come  performance  trade-offs.  Given  the  multiplicity 
of  subnets  with  their  varying  packet  sizes,  a  segmenting  capability  would  seem  appropriate  in  an  absence  of  realizing 
the  reliability  of  the  subject  subnets. 

Session  Layer.  The  Session  Layer  is  null  for  AFATDS  data  communications. 

Transport  Layer.  The  following  Transport  Layer  functions,  which  have  been  derived  from  the 
AFATDS  System/Segment  Specification  (SSS)  requirements  and  Concept  Evaluation  Phase  (CEP)  experience,  will 
be  supported  for  AFATDS  Version  1 . 

•  Connected  Data  Transfer 

•  Acknowledged  Unit  Data  Transfer 

•  Unacknowledged  Unit  Data  Transfer 

•  End  To  End  Acknowledgement 

■  Retransmission  on  Time  Out 

•  Segmenting  and  Reassembly 

•  Data  Sequencing/Resequencing 

•  Explicit  Row  Control 

•  Transport  Addressing 

•  Inactivity  Control. 

The  transport  layer  implementation  for  AFATDS  will  be  based  on  ISO  8073  (TP  4), 
ISO  8072,  ISO  8072/DAD  1,  ISO  8602,  and  ICST/HLNP-83  transport  layer  standards.  Due  to  the  unique  Fire 
Support  requirements  and  the  FS  operational  environment,  these  standards  will  be  extended  and  modified  as  necessary 
for  AFATDS  use. 

ISO  8073:  Information  processing  systems  •  Open  System  Interconnection  -  Connection  Oriented 
transport  protocol  specification;  also  ISO  8073/DAD  2:  Addendum  2:  Operation  of  Class  4  over  Connectionless 
Network  Service.  These  arc  the  standards  which  AFATDS  has  adopted  to  base  the  transport  mechanism  on. 
AFATDS  CEP  developed  a  transport  mechanism  based  on  NIST  recommendations  for  implementing  TIM  as 
promulgated  in  1CST/HLMP-83-3:  Proposed  FIPS  •  Specification  of  a  Transport  Protocol  for  Computer 
communication,  vol.  3;  Class  4  Protocol.  The  primary  extension  to  TP4  adopted  from  the  NIST  document  was  the 
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modification  of  UNIT_DATA  from  unacknowledged/unreliable  to  acknowledge/rcliaMe.  This  exteaskm  was 
developed  by  NIST  to  support  military  application  and  coincidentally  served  AFATDS  CEP  well.  Additionally 
specializations  to  the  TP4  protocol  were  made  in  CEP  to  meet  the  requirements  of  its  clients  and  the  diverse  nature 
of  die  subnetworks  (IEEE  802.5  to  CNR)  it  was  used  over.  Tuner  durations  were  modified  to  account  for  service 
delays  perceived  on  different  nets  and  to  account  for  non-responsiveness  of  clients  in  reacting  to  service  indications 
(e.g.,  connection  offers).  An  adaptive  retransmission  timeout  mechanism  was  developed.  Segment  sizes  were 
adjusted  per  the  servicing  networks  ability  (non-segmenting  network  used  in  CEP).  New  state  transitions  and 
protocol  data  units  were  introduced  to  account  for  AFATDS  specific  anomalies  or  needed  utilization  improvements. 
An  example  was  the  inclusion  of  large  amounts  of  user  data  in  CR  TPDUs  in  FIPS  type  UN1T_DATA  to  limit  the 
number  of  TPDUs  required  to  complete  an  acknowledged  "datagram”  especially  over  CNR.  This  AFATDS  CEP 
implementation  of  a  transport  layer  (in  Ada)  has  been  prated  to  AFATDS  VI  for  use  as  a  protocol  communication 
system  in  support  of  the  AFATDS  Inter-Software  Communication  (ISC)  prototype,  aid  portions  will  be  used  where 
possible  in  the  AFATDS  VI  objective  system  design  and  implementation. 

ISO  8062:  Information  processing  systems  -  Open  System  Interconnection  -  Protocol  for 
providing  the  connectionless-mode  transport  service.  Despite  having  needed  and  adopted  NIST  FTPS-style 
acknowledged  UNIT-DATA,  AFATDS  still  intends  on  availing  itself  of  the  more  original  ISO  unacknowledge 
UNIT-DATA  mechanism.  This  is  useful  especially  in  support  of  multicast  In  AFATDS  CEP  this  same  standard 
was  adopted  (in  draft  form)  and  mechanisms  were  developed  to  allow  multiple  endpoints,  or  TSAPs,  within  a  single 
workstation  to  receive  copies  of  a  single,  multi-cast  on  the  LAN. 

Presentation  Layer.  The  Presentation  Layer  is  handled  by  the  Tactical  Support  Operation 
(TSO)  function  in  AFATDS.  The  TSO  is  a  computer  software  configuration  item  (CSCI)  in  AFATDS  VI  that 
embodies  the  presentation  functions  necessary  to  afford  AFATDS  applications  the  ability  to  interoperate  with 
multiple  different  end  systems  many  of  which  have  different  transfer  syntaxes  (i.e.,  message  formats/sets).  TSO  acts 
as  a  translation  filter  on  transmission  from  AFATDS  applications,  proper,  which  can  be  destined  to  AFATDS  and 
non- AFATDS  systems  alike,  and  proxies  the  transmission  request  on  the  correct  procedural  interface:  Inter-software 
communication  (ISC)  for  intra-AFATDS  transfer  or  the  appropriate  external  system  (XQ  interface  for  non- AFATDS 
transfers.  In  the  intra-AFATDS  case,  the  ISC  delivers  the  transmission  to  the  destination  application  software  entity 
directly,  which  receives  it  via  TSO  proxy  routines  again.  In  the  non-AFATDS  case,  TSO  invokes  the  XC  function 
which  RPCs  (remote  procedure  call)  the  transmission  request  via  the  ISC  to  its  agent  XC  entity  at  the  respective 
external  system  "communication  gateway"  entity,  which  in  turn  acts  as  a  gateway  between  the  AFATDS  internal 
stack,  accessed  via  ISC,  and  the  external  stack  required  to  interact  with  the  non-AFATDS  system. 

TSO  fills  the  classical  role  of  application  gateway  as  well.  On  reception  of  a  message 
transmission  from  an  external  system,  the  appropriate  "communications  gateway”  entity  passes  the  message  off  to 
TSO,  which  then  translates  the  message  to  AFATDS  internal  format  and  forward  it  on  to  the  application  entity 
within  the  OPFAC  which  must  process  it.  This  hand-off  on  reception  is  done  because  external  systems  do  not 
address  their  transmissions  to  the  level  of  granularity  that  the  AFATDS  does.  In  essence,  the  other  systems  utilize  a 
one-level  address  space  where  addressing  consists  of  identifying  the  fire  support  unit  However,  AFATDS  utilizes  a 
two-level  name-space  where  each  intra-AFATDS  transmission  is  addressed  not  only  to  the  unit,  but  also  to  the 
specific  software  entity  within  the  unit,  which  by  the  way  may  be  configured  to  be  anywhere  within  a  multi¬ 
workstation  OPFAC.  This  is  because  AFATDS  is  the  first  distributed  system  in  the  US  fire  support  inventory 
coupled  with  the  engineering  capability  to  extend  transport  end-to-end  reliability  over  intemetted  tactical  networks, 
whereas  in  the  past  it  was  all  done  with  link  protocols.  At  any  rate,  TSO  is  required  to  determine  the  final 
destination  based  on  message  content  because  the  data  transfer  mechanism  was  not  given  complete  address 
information  by  the  external  system  per  AFATDS  standards. 

Application  Processes.  AFATDS  applications  processes  are  composed  of  ASEs  that  can  be 
classified  into  two  types:  Common  ASEs  and  Specific  ASEs.  Common  ASEs  are  those  that  provide  capabilities 
which  are  generally  useful  to  more  than  one  application  process.  Specific  ASEs  are  those  that  provide  capabilities  to 
satisfy  the  particular  needs  of  a  single  application  process.  An  ASE  may  invoke  the  services  of  another  ASE  within 
the  same  application  process.  Therefore,  Common  and  Specific  ASEs  are  combined  in  various  ways  to  create 
different  applications  processes.  Individual  ASEs  employ  Application,  Presentation,  and  Session  Layer  functions  as 
necessary  based  on  the  service  that  the  ASE  is  providing.  Therefore,  it  is  not  possible  to  identify  a  single  set  of 
application,  presentation,  and  session  protocols,  but  rather  these  layers  must  be  discussed  for  each  ASE  employed  by 
an  application  process.  The  specific  application  processes  and  ASEs  they  employ  are  described  below. 

Application  Layer  employs  two  services.  In  the  classic  case,  software  entities  access  the  data 
transfer  mechanism  directly  (ISC  in  AFATDS,  Berkley  Sockets,  or  TL1  in  UNIX)  and  perform  their  own  version  of 
the  required  functionality  typically  associated  with  the  upper  layers.  In  effect,  the  applications  use  their  own  ASE. 

Appendix  C  C-9  Example  National  Military  Initiatives 

UNCLASSIFIED 


UNCLASSIFIED 


This  is  especially  true  when  remote  procedure  call  (RPC)  paradigms  are  used.  RPC  is  an  underpinning  of  AFATDS 
given  its  distributed  nature  and  non-dctcrministic  configurability.  In  the  second  service,  application  level  software 
entities  access  data  transfer  by  utilizing  Message  Handler  Services  defined  as  Tactical  Support  Operation  (TSO). 
TSO  performs  some  application  control  functionality,  presentation  functionality  and  to  some  extent  handles  sessions 
with  external  systems  for  AFATDS  applications.  The  message  definition  effort  will  use  the  data  elements  and 
messages  as  defined  in  ACCS,  DoD  (Joint),  and  NATO  standards. 

2.4  Protocols  Provided  by  US  Army  TCIM  Hardware^ 

The  US  Army  Common  Hardware/Software  (CHS)  programs  include  a  Tactical  Communications  Interface 
Module  (TCIM).  Two  types  of  interfaces  are  provided.  Supported  by  an  internal  or  an  external  device,  Channel  1 
supports  the  Maneuver  Control  System  (MCS)  Version  10  Circuit  Switch  (CSW),  the  Marine  Tactical  System 
(MTS)  Mode  VII  CSW,  ITU-TS  X.25,  and  the  Army  Data  Distribution  System  (ADDS)  X.25  for  EPLRS.  The 
Version  1  interfaces  are: 

•  KY-68  (DSVT) 

•  TA-1035  (DNVT) 

•  KG-84  (DLED) 

•  AN/GYC-7  Unit  Level  Message  Switch  (ULMS) 

•  SB-3614  SB 

•  EPUU/JTIDS  (32  Kbps) 

•  4  Wire 

-  FSK-188C&B 

-  STANAG  4202  (Annex  A) 

•  Conditioned  Diphase. 

The  second  type  of  interface  is  available  cm  both  Channel  1  and  Channel  2)  and  is  also  supported  by  an 
internal  or  exemal  SCSI  circuit  card.  The  second  type  supports  all  the  interfaces  defined  by  Version  1,  together  with 
additional  interfaces  noted  beiow,  on  two  channels  (Channels  I  and  2).  The  Version  2  capability  supports  combat 
net  radio  with  the  following  added  interfaces: 

•  Combat  Net  Radio 

-  VRC-12  and  PRC-77 

-  SINCGARS 

-  GRC-193.  GRC-213 

-  PRC-104 

•  KY-57 

•  2  Wire 

-  FSK-188C&B 

-  STANAG  4202  (Annex  A) 

-  Conditioned  Diphase. 

The  following  requirements  were  added  as  follow-on  TCIM  requirements  for  field  tests  in  1992: 

•  AFATDS: 

-  T ACF1RE  protocol  (6(9/1 1/8)  software 

-  NATO  STANAG  5620  software 

-  MTS  switched  software 

-  ADDS  interface  software 

-  VMF  TTDP  software 

-  TCIM/TCU  interface 

-  KG-84C 


5  This  section  is  based  on  the  following  contribution:  CHS  Communications  Program,  Briefing,  Draft,  'an 
Levine,  OPM  CHS,  US  Army  CLCOM,  December  1991,  UNCLASSIFIED;  and  a  private  communication  with 
Stan  Levine  in  February  1994  [Ref.  Levine  1994c]. 
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•  FAADC21 

-  Multiple  TOM 

-  ADDS  interface 

•  TCJM/TCU  interface 

•  ADDS 

-  ADDS  interface  software 

-  128  Kbps  baud  rate 

-  200  packages  per  second  (pps)  throughput 

-  Two  programmable  PJH  channels 

-  TC3M/TCU  interface 

•  Marine  Corps 

-  MTS  switched  software 

-  MTS  broad  cast  (Class  I)  software 

-  ULS  autodial  interface  software 

-  KG-84C  interface  software 

•  MCS  follow-on  requirements 

•  FS  AC  foUow-on  requirements. 

The  overall  architecture  for  the  communications  software  interfaces  between  the  physical  device  (SCSI  But) 
and  the  Layer  3  services  provided  by  tbe  Unit  Level  Processor  (ULP)  is  shown  in  Figure  C-7. 

nn 
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3.  EXAMPLE  PROFILES  FOR  BROADCAST  MEDIA 

3.1  Example  of  a  Broadcast  Profile  for  Data  Communications  Using  Tactical 
Radios 

This  section  uses  the  OSI  Reference  Model  and  interoperability  parameters  to  identify  interpretations, 
extensions,  and  deviations  to  OS!  and  other  standards  in  the  specification  of  a  set  of  protocols  used  to  support  data 
transmission  over  combat  net  radio  by  the  U.S  Marine  Corps.  These  protocols  are  specified  in  Volume  V  of  the 
Marine  Corps  MTS  TIDP. 

The  MTS  protocols  were  developed  based  on  U.S.  federal  standards  in  the  late  1970s.  Many  of  the  standards 
selected  have  become  ISO  standards,  and  the  structure  of  the  MTS  protocols  can  be  interpreted  in  terms  of  the  seven- 
layer  OSI  Reference  Model.  The  MTS  broadcast  profile,  discussed  in  this  section,  is  now  being  used  by  the  Army 
and  the  Marine  Corps  as  the  basis  for  defining  the  initial  protocol  standards  to  be  used  in  the  TIDP  now  being 
developed  for  Joint  Interoperability  of  Tactical  Command  and  Control  Systems  (JINTACCS)  K-Series  Variable 
Message  Format  (VMF)  bit-oriented  messages.  The  K-Series  messages  and  associated  data  communications 
protocols  arc  being  specified  by  the  joint  Fire  Support  Subgroup  (FSSG)  of  the  Joint  Multi-TADIL  Standards 
Working  Group  (JMSWG)  under  the  auspices  of  the  Joint  Tactical  C3  Agency. 

Table  C-l  highlights  the  features  provided  in  the  broadcast  protocol,  used  in  Marine  Corps  tactical  data 
systems  (TDSs),  for  each  of  the  seven  layers.  It  further  identifies  the  standards  used  in  each  layer  and  notes  the 
interpretations,  exceptions,  extensions,  and  deviations  that  were  specified. 

Military  features  supported  by  the  broadcast  protocol  standard  and  identified  in  Table  C-l  include: 

•  Multiaddressing  (Layer  7,  through  the  Message  Header,  and  Layer  2,  through  the  extended  address 
field) 

•  Data  integrity  and.  more  generally,  the  capability  to  operate  in  a  high  bit-enor-rate  environment 
[Layer  2,  through  use  of  a  32-bit  frame  check  sequence  (FCS)  for  error  checking  and  the  (23,12) 
half-rate  Golay  error  detection  and  correction  coding  (ED&C),  together  with  16x24-bit 
interleaving] 

•  Use  of  XID  command  and  response  (Layer  2) 

•  Control  of  emanations  by  senders  and  recipients  through  provisions  for  optional 
acknowledgements  (ACKs)  (Layer  7-request  for  ACK  is  part  of  the  message)  and  for  not  sending 
ACKs  even  when  requested  (Layer  2),  both  under  operator  control 

•  Limit  on  the  number  of  retransmissions  permitted  (Layer  2) 

•  Providing  for  net  access  (uses  an  international  standard  in  Layer  2  for  handling  media  access 
contention  and  collision  detection6  and  defines  an  algorithm  for  wait  times  for  reattempting 
access);  net  access  algorithms  could  be  extended  to  support  precedence  and  preemption. 


4.  EXAMPLE  PROFILES  FOR  TACTICAL  SWITCHES 

4.1  Example  of  a  "Datagram"  Switched  Protocol  Standard  for  Tactical  Radios 

This  section  summarizes  a  set  of  protocols  used  to  support  data  transmission  through  tactical  data  switches 
by  the  U.S.  Marine  Corps.  These  arc  the  MTS  switched  protocols  tbat  are  specified  in  Volume  V  of  the  Marine 
Corps  Technical  Interface  Design  Plan  for  Marine  Tactical  Systems. 

Table  C-2  highlights  the  features  provided  in  the  switched  MTS  protocol  for  each  of  the  seven  layers.  The 
table  identifies  the  international  and  U.S.  standards  used  in  each  layer,  and  notes  the  interpretations,  exceptions, 
extensions,  and  deviations  that  are  specified. 


6  The  listen-bcforc-talk  contention  method  is  called  Carrier  Sense  Multiple  Access  with  Collision  Detection 
(CSMA/CD). 
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Table  C-1.  A  Functional  Profit*  of  Broadcast  Protocols  Uaad  In 
Tactical  Systems  by  tha  U.S.  Marina  Corps 


• 

ISO  Layar,  Function 

Standards  Cited 

Notes  on  Interoperability 

Parameters 

7 

Mag  Header 

Mag  Acknowledgment 

Non* 

Non* 

Supports  multipie  addresses,  precedence, 
and  security  classification. 

6 

Msg  Format 

None 

Uses  the  same  flagging  schema  as  the 
syntax  adopted  for  U.S.  JINTAGCS  K-series 

messages. 

Information  Field  Size 

None 

Maximum  message  length  is  3500  octets. 

o 

Nona 

N/A 

Nul  layer. 

E 

Non* 

N/A 

Nul  layer. 

B 

Maesags  Segmenting 

N/A 

Messages  are  not  segmented. 

2 

Frame  Formatting 

ISO  3308/7809  (HDLC) 
with  Options  7  and  14 

Opt  7*Extended  Address  Field;  2-17  octets 
(base  std  is  one  octet;  Opt  7  specifies  no 
maximum  on  extended  address  field  size). 
Opt  14a32-blt  frame  check  seq  (FCS) 

(base  standard  is  16-M  FCS). 

Frame  Addressing 

ISO  3309 

Commands  &  Responses 

ISO  4335/7809 
with  Option  1 

Opt  1-XID. 

Does  not  support  SABM,  DISC  cmds  and 
FRMR.UA, DM  rasp  (radto  application). 

Does  not  st^ipoit  P/F  M. 

Madia  Access 

No  standard  apples 

Uses  CSMA/CD  w«h  unique  algorithms  lor 
raattempUng  access  to  net 

Data  Link  Initialization 

and  Release 

ISO  4335/7809 
wlh  Option  1  (WD) 

XID  is  used  during  net  establshmenL 

Frame  Transfer 

ISO  4335/7809 

Uses  all  3  types  of  frames. 

Acknowledgment  (ACK) 

ISO  4335 

ACK  is  optional.-  when  invoked.  ItfoBows 
the  standard. 

Retransmission 

Not  controled  by  standards 

Max  2  retries  (under  operator  control) 

(no  provision  for  setting  a  max  in  stds). 
Standards  suggest  use  of  P/F  bit  to  control 
retransmission. 

EO&C-Error  Detection 

IS  3309/7809  W  Opt  14 

32-b*  FCS  (algorithm  is  ISO  3309. 

Sec  3.6.3). 

ED&C-EnorCodng 

Net  controled  by  standards 

(23,12)  half-rate  Gotey;  24th  bk  is  zero 
filed  (delects  Ofcorrects  3  errors  in  each 
24-bit  cods  word). 

EMC- Interleaving 

Not  controled  by  standards 

16x24-M  time  dispersive  coding  (TDC). 
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Table  C-1.  (Continued) 


r 

Notes  on  Interoperability  , 

|  ISO  Layer,  Function 

Standards  Cited 

Parameters 

1 

-Electrical 
-Voltage  Levels 

MIL-STD-188-1 14 

[Similar  to  CCITT  V.10/X.26] 

-Load  Impedance 

MIL-STD-188C 
MIL-STD-1 88/24(Prt2) 
MIL-STD-188-1 41 

Mechanical 

-Connectors 

MIL-STD-242G(Prt8) 

MIL-P-55149 

Cable  Lengths 

MIL-STD-242G(  Prt8) 

Functional  (pin  assign) 

MIL-STD-242G(Prt8) 

Procedural 

-COMSEC  PrcVPostamble 
Frame  Placement 

DCT  Spec 

-Keytime  Delay 

DOT  Spec 

-Bit  Synchronization 

DCT  Spec 

-Transmission  Synch 

DCT  Spec 

-Clocking  Ctrl  &  Timing 

N/A 

References: 

1.  Technical  Interface  Design  Plan  for  Marine  Tactical  Systems  (MTS  TIDP),  Volume  V, 
Protocol  Standard.  Headquarters,  U.S.Marine  Corps.  July  1987.  UNCLASSIFIED. 

2.  Discussions  with  Systems  Integration  Directorate,  MCRDAC,  and  LOGICON/Eagle 
Technology.  Inc.,  March  1989. 
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Table  02.  A  Functional  Proflla  of  'Datagram*  8whchad  Protocols  Uaad  In 
Tactical  Systama  by  tha  U.S.  Marina  Corpa 


Mom  on  tntrrpptnMHty 

ISO  Layer,  FuneScn 

ParamaMra  | 

T 

Msg  HwNr 

Nona|i) 

Supports  muNpfts  addrassas.  praoadanoa,  and 

luteg  Acfoowtadgmant 

Nona 

aacurtty  ctaaaMcMion. 

H 

Mag  Foma 

None 

•  Uaasthaaame  flagging  schema  as  8m  syntax  adopted 
tar  US  JNTACCS  K-Sariaa  maaaagaa 

1 

MomtaDon  Field  Size 

Nona 

•  Max  N  40  aagments.  200  octets  par  segment  (maaaaga 
langta) 

as. - 

nona 

N/A 

•  NUI  layer 

H 

End-End  Sequence  Control 

Nona 

•  Tranaport  layer  aocumulalaa  and  ordara  packals  tar 
uaan;  uaaa  7  octets  (vice  20-80  odata  tor  TCP) 

■ 

End-End  CongaatkxV 

Nona  found 

•  ConnsckontsaA-oriantad  tayar,  a  variant 

■ 

HoarConM 

of  TP4 

3 

rMwofK  nounvoWRcnaig 

Nona  found 

•  Conoackontaaa-oriantad  wfth  daHnninialic 
fouling  [21 

•  Supports  Itaaflng*  hoal,  using  opanlor-MIMed 
dboomact  and  raoonnacl.  but  requiring  no  change  of 

Maaaaga  Segmenting 

Not  oonfradad  by  alandarda 

Packet  Addreealng 

Nona 

•  Uaaa  unique  Social  routing  indtaator  and  praridae 
tar  muMpla  addraaaing  tor  up  to  18  daalinMtone 

Packs!  Prsoadanos 

Nona 

•  Uaaa  3  cfaaaaa  of  praoadanoa  (SyaCom.  Dalai.  Qata2). 

In  which  mNary  praoadancaa  (Y-Z-O-P-fl)  am 

handtod  as  OaU2 

NatworiiFLowA 

Nona  found 

•  Tndftc  from  aubacribara  can  ba  Imftad  on 

praoadanoa;  trafBc  in  natvrorkia  prooaaaad  by  pnokat 
praoadanoa 

End-End  Error  Recovery 

Nana 

Dafeacta  loss  of  maaaaoa  framaa.  wttti  notMctcafion 

(Message  Accountability) 

tar  nonparlahabla  maaaagaa 

Conpaation  Control 
mismsiang 

N/A 

•  Not  supported 

2 

i  him  naTOnny 

ISO  3308/7806  (HOLC) 

#  Opt  10  cafe  for  artandad  control  bald  (two  ootala) 

wCh  Options  10  and  14 

•  U-frama  is  emended  (two  odals)  [3[ 

ANSI  X3.66-1078  (ADCCP) 
(MtLiae  TRf-TAC  Mode  VH) 

•  Opt  14  cals  tor  32-M  FCS 

Frama  Addressing 

ISO  3300 

*  Swtanaddraaa vartaa [4] 

Commidi  ft  Rasponsas 

ISO  4335/7008  whh 

•  SIM  and  may  be  initialed  tfbota  Stallone  tor  Ink 

addTI  Option*  2.4.5,8.11 

MWzaltan 

[51 

*  RM  raaponaa  not  bnplantanlod 

•  Ooaa  not  aupport  poMnai  (P/F)  bk 

Madia  Acoaaa 

N/A 

•  Whan  aatablahad  (WMaiiad).  luMupit 
point-to-poM  Ink  has  no  aooaas  contention 

Data  Link  HHaRzaDon 

ISO  4336/7800 

•  Addraaaas  security  Owough  uaa  of  UMramaa  fi) 

and  Ralaaaa 

ANSI  X3  88-1878  (ADCCP) 
TRf-TAC  C0 16 

Frama  Trarafer 

ISO  4335/7800 

•  Uaaa  al  3  typaa  of  framaa 

Acknowledgment  (ACK) 

ISO  4335 

•  ACK  or  NAK  is  required 

RaMramMon 

1904336 

•  Maximum  of  5  ralhaa 

•  Flair  anew  laainn  la  aUomaHc  «  no  ACK  [7) 
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ISO  Layer,  Function 

Standards  Cited 

Notes  on  Interoperability 

Parameters 

1 

-Electrical 
-Voltage  Levels 
-Load  Impedance 

MIL-STD- 188-1 14 
MIL-STD-188C 
MIL-STD-188/24(Prt2) 
MIL-STD-188-141 

[Similar  to  CCITT  V.10/X.26] 

Mechanical 

-Connectors 

Cable  Lengths 

Functional  (pin  assign) 

MIL-STD-242G(Prt8) 

MIL-P-55149 

MIL-STD-242G(Prt8) 

MIL-STD-242G(Prt8) 

Procedural 

-COMSEC  Pre/Postamble 
Frame  Placement 
-Keytime  Delay 
-Bit  Synchronization 
-Transmission  Synch 
-Clocking  Ctrl  &  Timing 

DCT  Spec 

DCT  Spec 

DCT  Spec 

DCT  Spec 

N/A 

References: 

1 .  Technical  Interface  Design  Plan  for  Marine  Tactical  Systems  (MTS  TIDP),  Volume  V, 
Protocol  Standard.  Headquarters.  U.S. Marine  Corps.  July  1987,  UNCLASSIFIED. 

2.  Discussions  with  Systems  Integration  Directorate.  MCRDAC,  and  LOGICQN/Eagle 
Technology.  Inc.,  March  1989. 


5.  COMPARISON  OF  TACTICAL  PROFILES 

5.1  Comparison  of  US  Data  Communications  Broadcast  Protocols  Based  on  HDLC 
for  Digital  Entry  Devices  (DEDs)7 

Note:  STAN  AG  4202  is  used  for  combat  net  radio  to  send  STANAG  5500  message  text  formats.  Its 
interoperability  parameters  are  discussed  in  Appendix  A. 

Purpose.  This  paper  compares  Marine  Tactical  Systems8  (MTS)  and  Variable  Message  Format9  (VMF) 
broadcast  data  link  layer  protocols  to  High  Level  Data  Link  Control10  (HDLC)  and  other  data  link  protocols.  All  of 
these  protocols  are  candidates  for  a  Digital  Entry  Device  (DED)  protocol.  This  comparison  identifies  modifications 
to  the  base  HDLC  standard  to  accommodate  a  particular  feature  of  a  subnetwork  technology  It  provides  insight  to 
the  reasons  for  deviations  from  the  standard. 

Background.  The  VMF  data  communication  data  link  protocol  (Layer  2  of  the  OSI  Reference  Model)  is 
being  developed  for  initial  use  as  a  broadcast  protocol  to  operate  with  UHF,  VHF,  and  HF  single  channel  radios. 


7  This  section  is  based  on  a  contribution  from  the  US  Marine  Corps,  Comparison  of  the  MTS  Broadcast,  VMF, 
and  Other  Data  Link  Standards  Based  on  HDLC,  Draft,  MCRDAC/Integratioo  (Maj.  M.  Mascarenas),  15 
November  1991,  UNCLASSIFIED. 

8  Marine  Tactical  Systems  Technical  Interface  Design  Plan  ( MTS  TIDP),  Volume  V,  Protocol  Standard,  US 
Marine  Corps.  July  1987.  UNCLASSIFIED. 

9  Variable  Message  Format  TIDP,  Volume  IV.  Protocol,  February  1991,  UNCLASSIFIED. 

1 0  ISO  4335,  High  Level  Data  Link  Control  (HDLC)  Procedures,  Third  edition,  1987;  ISO  3309,  High  Level  Data 
Link  Control  -  Frame  Structure,  Third  Edition,  1984;  and  ISO  8885,  High-level  Data  Link  Control  Procedures  - 
General-Purpose  XID  Frame  Information  Field  Content  and  Format,  First  Edition,  1987. 
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VMF  and  Ak  Faroe  Application  Program  Development11  (AFAPD)  are  closely  related  to  the  Marine  Tactical 
System  (MTS)  broadcast  protocol  VMF,  AFAPD,  and  MTS  are  baaed  on  ISO  4333  High  Level  data  fink  control 
(HDLC)  procedures  and  ISO  3309  HDLC  frame  structure. 

Tbe  HDLC  standard  offers  a  range  of  option  selections  and  operating  inodes  that  have  been  used  far  a  variety 
of  station  and  network  types  (e.g.,  point-to-point,  multi-link,  broadcast).  Some  of  tbe  flexibility  built  into  HDLC 
includes  tbe  following: 

•  A  broad  set  of  commands  and  responses 

•  Procedures  for  primary,  secoodary  and  combined  stations 

•  Procedures  for  half  aod  full  duplex 

•  An  extendable  control  field 

•  ADexcKSnCKureu  noa 

•  A  variable  information  field 

•  Conventions  to  allow  group  and  global  addressing 

•  A  set  of  14  option  functions. 

Specialized  data  link  standards  have  been  created  by  selecting  from  tbe  set  of  options  or  through 
modifications  to  tbe  HDLC  to  provide  special  services.  One  such  modification  occurs  in  the  address  field.  The 
address  field  of  HDLC  only  allows  one  address  that  identifies  tbe  destination  of  a  command  and  the  source  of  a 
response.  In  broadcast  type  networks  that  have  only  combined  stations,  all  stations  receive  the  command  or  response 
and  any  station  might  have  been  tbe  originator.  Both  the  source  and  destination  addresses  are  required  to  remove  any 
ambiguity.  For  that  reason,  data  link  protocols  for  broadcast  type  networks  modify  the  address  field  to  allow  at  least 
two  addresses,  source  and  destination. 

The  following  are  tbe  data  link  standards  that  are  based  on  HDLC  and  used  in  this  comparison; 

(1)  X.23  LAPB-  X.25  LAPB  uses  the  HDLC  class  of  procedures  for  balanced  asynchronous 
combined  (BAC)  stations  and  includes  HDLC  options  2, 8,  and  10.  It  is  intended  for  point-to- 
point  or  multipoint  configurations. 

(2)  ISO  8802-2.  ISO  8802-2,  Logical  Link  Control12  (LLC)  defines  two  modes  of  operation, 
connection-oriented  (CO)  and  connectionless  (CL),  both  of  which  are  based  on  HDLC  for  BAC 
stations  in  a  broadcast  network.  It  deviates  from  the  HDLC  standard  frame  format  to  provide 
both  tbe  source  and  destination  addresses  required  in  a  broadcast  network.  The  cormectioo- 
oriented  sendee  uses  the  basic  commands  and  responses  for  BAC  and  adds  HDLC  options  2, 7 
andlO.  Hie  connectionless  service  is  a  reduced  set  of  enmmands  and  responses,  but  adds  HDLC 
options  1, 4  and  12. 

(3)  MTS  Bmtlcatt.  The  MTS  data  link  broadcast  protocol  offers  a  connectionless  service  in  a 
broadcast  network.  It  is  based  oo  a  reduced  set  of  HDLC  commands  and  responses  and  indudes 
HDLC  option  1,  7  and  14.  MTS  deviates  in  tbe  address  field  to  include  multiple  destination 
addresses  for  the  broadcast  network. 

(4)  ADAPO-  AFAPD  is  based  on  the  MTS  broadcast  protocol  with  a  change  in  the  address  field  to 
provide  a  mechanism  for  frame  relay. 

(5)  YMF-  VMF  is  a  newly  created  joint  US  DoD  (under  consignment  by  JTC3A)  protocol  based 
on  HDLC  that  is  also  closely  related  to  both  the  MTS  and  ISO  8802-2.  It  provides  both  tbe 
coonectioo-oriented  and  connectionless  sets  of  procedures  and  modifies  the  definition  of  both  the 
address  and  control  fields.  The  connection-oriented  set  uses  the  BAC  class  of  procedures  and 
HDLC  options  1,  2,  3,  7, 11,  and  14.  The  connectionless  operation  is  identical  to  the  MTS 
operations. 

Discussion.  Table  C-3  shows  a  comparison  of  frame  formats  and  functions  performed  by  the  HDLC, 
X.23  LAPB,  ISO  8802-2,  MTS,  VMF,  and  AFAPD  data  link  protocols.  The  following  paragraphs  discuss  each  row 
of  Table  A-l  to  highlight  the  areas  of  deviation  and  to  explain  the  remons  for  the  deviation. 

a  Frame  Formal  Only  ISO  8802-2  varies  from  the  HDLC  frame  format  because  it  does  not  have  the 
Frame  Check  Sequence  (PCS)  or  Flag  fields.  Ibis  is  primarily  because  8802-2  is  used  with  a  Media  Access  Control 
(MAC)  layer,  which  provides  the  PCS  and  Flag  field  functions,  so  the  Adds  tat  ISO  8802-2  would  be  redundant. 


1 1  Program  Design  Specification  for  the  Air  Force  Application  Program  Development  (AFAPD)  for  the  Digital 
Communications  Terminal  (DCT),  AN/PSC-2,  US  Air  Force  (TAC/DRI),  May  1989,  UNCLASSIFIED. 

12  ISO  8802-2,  Logical  Link  Control  First  Edition,  1989. 
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b.  Control  Field  Size.  Only  VMF  for  type  2  service  varies  from  the  HDLC  standard.  A  control  field 
exists  for  each  destination  address  to  allow  multiple  addressing  in  the  connection-oriented  mode  at  the  link  (there 
is  no  upper  layer  connection).  The  sequence  windows  are  different  for  each  of  the  destination  addresses.  Therefore, 
the  control  field  contents  arc  different  for  each  destination.  The  control  field  size  per  destination  is  a  fixed  size,  one 
byte. 

c.  Control  Field  Size  Determination  Only  VMF  differs  from  the  HDLC  standard.  In  VMF.  the  size  of 
the  control  field  varies  in  relation  to  the  number  of  destination  addresses.  The  control  field  is  composed  of  1  to  16 
one-byte  control  subfields.  The  other  standards  have  control  fields  that  are  fixed  by  agreement  to  one  or  two  bytes. 
The  VMF  variation  accommodates  multiple  addressing  in  a  connection-oriented  environment.  However,  the  control 
field  size  per  destination  is  determined  at  initialization,  since  the  VMF  standard  only  allows  the  SABM  (not  the 
SAB  ME)  control  format  that  designates  the  one  byte  control  field. 

d-  Control  Field  Formats.  All  of  the  HDLC  variants  choose  the  formats  from  the  complete  set  of 
HDLC  formats  according  to  the  needs  of  the  protocol.  All  of  the  connection  oriented  protocols  (LAPB,  and  Type  2 
services  in  ISO  8802-2  and  VMF)  use  the  basic  set  of  control  field  formats  and  one  or  more  from  the  optional 
formats.  The  connectionless  mode  protocols  (MTS  and  Type  1  services  in  ISO  8802-2  and  VMF)  use  a  subset  of 
the  HDLC  basic  control  field  formats,  because  those  pertaining  to  the  connection  set-up,  maintenance,  and 
disconnect  are  not  required. 

e  Address  Field  Sire  A  variance  in  this  field  is  allowed  by  the  basic  HDLC  protocol.  While  the  size 
of  the  address  can  vary  according  to  the  HDLC  standard,  only  one  address  is  allowed.  ISO  8802-2,  MTS,  AFAPD, 
and  VMF  have  all  extended  the  address  field  for  the  purpose  of  including  the  source  address  as  well  as  the  destination 
address.  Those  protocols  are  not  point-to-point  so  the  source  is  not  obvious  (as  it  is  in  the  LAPB  point-to-point 
protocol).  MTS,  VMF,  and  AFAPD  have  further  extended  the  field  to  allow  multiple  destination  addresses  (an 
expansion  of  the  group  address).  MTS,  AFAPD.  and  VMF  use  the  HDLC  method  [least  significant  bit  (LSB) 
indicator]  to  extend  the  field.  ISO  8802-2  uses  the  LSB  for  another  purpose  but  has  a  fixed  size  address  field. 
AFAPD  further  extends  and  modifies  the  address  field  to  provide  a  frame  relay  function.  The  length  of  the  field 
depends  of  the  number  of  destinations  and  the  use  of  the  relay  function. 

•  MTS,  AFAPD,  and  VMF  use  the  HDLC  address  extension  method  (LSXB)  to  lengthen  the 
address  field.  Within  the  longer  field,  MTS  and  VMF  identify  subfieids  for  the  source  and  one  or 
more  destination  addresses.  ISO  8802-2  defines  two  address  fields  that  are  each  one  byte  long. 
ISO  8802-2  does  not  use  the  LSB  to  indicate  the  extended  address  field.  That  bit  indicates  a 
group  address  in  the  destination  address,  and  a  command  or  response  in  the  source  address. 

•  VMF  designates  an  address  (value  =  l)  to  have  additional  special  significance  within  that 
protocol.  The  address  equal  to  1  is  used  to  indicate  the  frame  is  in  the  Type  2  service  format. 
(ISO  8802-2  also  allows  both  Type  I  and  Type  2  service.  The  service  types  are  distinguishable 
in  ISO  8802-2  because  they  contain  exclusive  sets  of  control  field  formats.) 
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Tabl#  C-3.  Comparison  of  Example  Broadcast  Protocols  with 
HOLC,  X.25  LAP  B,  and  LLC 


HDLC7S09 

Xti 

SOU 

MTS 

SAC 

LAPS 

LLC 

BROADCAST 

VMF 

AFAPD 

Frans  Formal 

Ftag  Artrtoaa 

Seme 

OSAP.SSAP 

Sams 

Same 

Same 

Control  Into 
CflCRao 

Confrol.  Into 

Control 

Extendable  1 

Same 

2  Bytes  tori 

1  Byte  only 

1  Byte  only 

1  Byte  only 

FttJ 

or  2  By  lee  tor 

POU  and  S 

Stzs 

IPOUandS 

POU.  iByia 

POU.  IByta 
torSPOU 

tor  U  POU. 

Contol 

At  Link 

At  Link 

Fixed 

Fixed 

Fkad 

Fkad 

FMdStas 

Dtiarmination 

Sal-Up 

Sal-Up 

Contol  Field 

(1  no  options) 

Crmm  Reap 

Type  1 

Same  ae  MTS 

Formate 

Comm  Raao 

1  1 

RR  RR 

Comm  Rase 

1  1 

DAD  DAD 

rWI  rVwi 

Ul 

miw  nasi 

rwt  nwi 

RR  RR 

SABM  UA 

XJD  XD 

XJD  XD 

nert  DAD 

rwwi  mt 

SABME  DM 

TEST  TEST 

rieirt  DAD 

itoWi  mn 

SABM  UA 

DISC  DM 

OSC  FRMR 

Type  2 

XD  XD 

kbud 

mwi 

Type  2 

wNh  options 

1  1 

add: 

RR  RR 

1  1 

SABME 

BAD  DAD 

mn  mn 

RR  RR 

XD  XX) 

SABME  UA 

wesy  west 

mn  rsen 

SREJ  SREJ 

06C  DM 

SABM  UA 

Ul  Ul 

REJ  FRMR 

0GC  0M 

REJ  REJ 

RSET  REJ 

REJ  FRMR 

SM  RM 

UP 

TEST  TEST 
RSET 

RD 

SREJ 

Address 

Extendable  1  to 

1  Byte 

2Bytes 

2-17  Bytes 

2-17  Bylee 

3-20Bytos 

Raid  Six* 

XX  Bytes 

Address 

Source:  None 

11000000  or 

Source:  7 

Souroe:  7 

Sotaoe:  7 

Source 

Raid 

Deeanelon: 

10000000 

BIS  1-126 

Blto  1-126 

Bte  2-96 

Originator 

Formas 

Global- 

OasiMion: 

OaattoeMon: 

Daatoaton: 

Direct 

11111111 

Global- 

Global- 

Global- 

OnliMlion 

Group -by 

11111111 

11111111 

11111111 

Agreement 

Group- 

No  Staton. 0 

Group- 

FMg 

No  Staton 

1XXXXXXX 

Range-0-127 

XXXXXXX1 

Hop  Count 

-0 

No  Staton 

No  Slaton. 0 

Raley  Deeiln- 

Range -0-2S6 

-0 

SpacW-1 

aton 

or  0-127* 

Range -0-127 

Extended 

■■y-M 

Address 

LSB 

Fixed 

Fixed 

LSB 

LSB 

LSB  and  Relay 

FMdSfea 

Datormfnatfon 

Functon 
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Table  C-3.  (Continued) 


HDLC  7S0A 
BAC 

X.26 

LAPS 

•02.2 

LLC 

MTS 

BROADCAST 

VMF 

AFAPD 

Info  Field 

Size  Max 

Any  #  of  Bits 

259  Bytes 

Any  #  of  Bytes 

3500  Bytes 

Negotiable 

Max  «  3500 

3500  Bytes 

FCS 

16  Bit  or  32  Bits 
(Option  #14) 

16  Bit 

None 

32  B4 

32  Bit 

32  bit 

P/F  W 

P  -  One  out¬ 
standing  Re¬ 
quest 

F-  Set  in 
response  to 
reoeivedPBit 

Sams 

Same 

Same  except  for 
the  XID 
exchange 

Same 

Same 

Sequence 

Numbers 

0-7  or  0-127 

0-7  or  0-127 

0-127 

Not  Used 

0-7 

Not  Used 

Link  Set- up 
Disc 

SABM  -»  UA 

SABME  -*  UA 

DISC  -.UA 

SABM  UA 

or 

SABME  -»  UA 

DISC  -.UA 

Type  1 

Not  Used 

Type  2 

SABME  -»  UA 
DISC  -.UA 

Not  Used 

Typel 

SABM  -»  UA 

DISC  -»  UA 

Type  2 

Not  Used 

Not  Used 

Network 

Control 

XID 

None 

Typel 

XID 

Type  2 

None 

XID 

Typel 

XID 

Type  2 

XID 

Not  Used 

•  AFAPD  address  field  content  is  identical  to  MTS  if  there  is  no  relay  destination.  However,  the 
address  field  has  several  additional  subfteids  for  the  relay  function,  there  are  two  source  addresses 
instead  of  one  (the  originator  and  the  current  transmitting  link  address)  and  two  destination  fields 
(the  final  destination  and  a  relay  destination).  There  are  three  additional  subfields  (relay,  flag,  and 
hopcount)  that  are  used  in  the  relay  process. 

g.  Address  field  size  determination.  ISO  8802-2  deviates  from  HDLC  because  it  defines  two  separate 
address  fields  of  one  byte  each.  It  does  not  use  the  LSB  to  indicate  an  address  field  longer  than  one  byte.  AFAPD 
field  size  depends  on  the  number  of  destination  and  if  relay  is  requested. 

h.  Information  Field  Size  Maximum.  Each  protocol  adheres  to  the  HDLC  standard  because  HDLC 
allows  any  information  field  size. 

i.  FCS.  ISO  8802-2  does  not  use  the  FCS  field  because  the  LLC  is  used  with  a  MAC  layer  which 
provides  the  FCS  functions.  All  of  the  other  protocols  use  either  the  basic  (16  bit)  or  optional  (32  bit)  FCS  as 
allowed  by  the  HDLC  standard. 

j .  P/F  Bit.  MTS  broadcast  protocol  follows  the  P/F  standard  for  I-frame  exchanges,  but  not  in  the  XID 
exchange. 

k.  Sequence  numbers.  ISO  8802-2  MTS,  and  VMF  do  not  use  sequence  numbers  in  the  connectionless- 
mode  of  service.  Sequence  numbers  are  used  for  flow  control  and  sequencing  that  are  not  functions  of  the  CL 
service. 

l.  link  Set-up  and  Disconnect.  All  of  the  protocols  that  provide  a  connection-oriented  service  adhere  to 
the  HDLC  standard  for  the  link  set-up  and  disconnect  The  connectionless  service  mode  in  MTS,  VMF,  and  ISO 
8802-2  do  not  perform  this  function. 

m.  Link  Control  The  XID  command  is  an  optional  command  and  response  in  HDLC.  ISO  8802-2  and 
VMF  use  the  XID  format  to  pass  link  control  information  in  the  information  field  according  to  ISO  8885  -  HDLC 
procedures  -  General  purpose  XID  frame  information  field  content  and  format  MTS  and  .AFAPD  use  the  XID  with  a 
one-byte  information  field  for  link  initialization  but  do  not  follow  ISO  8885  rules  to  identify  the  XID  information 
field  content. 
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S.2  Comparison  of  US  Data  Communications  Broadcast  Protocols  Planned  for  Use 
In  Land  Warfare  Fire  Support  CCISs13 

Overview.  MTS  broadcast  standard,  VMF,  and  AFS-BOM14  are  all  bit-oriented  communication 
protocols  that  have  a  data  link  layer  to  support  combat  net  radio,  a  broadcast  communicators  medium.  VMF  and 
AFS-BOM  were  produced  in  parallel  with  the  same  Army  and  Marine  Corps  representatives  and  are  based  on  the 
MTS  protocol.  In  fact,  the  VMF  specification  was  written  using  the  MTS  TIDP,  Volume  V,  as  the  beginning  text 
This  section  compares  the  functional  differences  among  the  MTS,  VMF,  and  AFS-BOM  protocols  and  evaluates 
their  ability  to  interoperate. 

Functional  Differences.  Table  C-4  lists  the  functions  performed  at  each  of  the  layers  and  briefly 
states  the  differences  among  the  protocols. 

a.  Physical  I  .aver.  There  are  no  functional  differences  among  the  protocols  in  this  layer. 

b.  Data  Link  Laver.  Listed  below  are  three  functional  differences  among  the  protocols. 

•  Media  Access  The  VMF  protocol  implements  both  a  random  and  a  prioritized  method  of 
calculating  the  net  access  delay  (NAD)  time.  MTS  only  implements  the  random  method,  and 
AFS-BOM  only  implements  the  prioritized  method.  Since  VMF  implements  both  schemes,  the 
different  media  access  schemes  only  create  an  interoperability  problem  between  tbe  MTS  and 
AFS-BOM  protocols.  Since  tbe  VMF  protocol  was  developed  to  provide  Marine  Corps  and 
Army  fire  support  interoperability,  there  is  not  a  problem. 

•  Connection  Establishment  and  Release  An  XID  exchange  is  currently  being  developed  for  the 
VMF  protocol  that  will  be  incompatible  with  either  tbe  MTS  or  AFS-BOM  XID  exchange.  It 
is  unknown  at  this  time  whether  AFS-BOM  will  incorporate  this  change.  In  any  case,  tbe  XID 
is  not  mandatory  for  initialization,  so  this  difference  will  not  prohibit  interoperability. 

•  Acknowledgement.  During  development  of  the  VMF  and  AFS-BOM  protocols,  a  change  was 
made  to  the  list  of  conditions  that  must  be  met  in  a  frame  before  the  data  link  layer  will  transmit 
acknowledgement  of  tbe  frame.  Ibis  change  only  affects  tbe  action  within  an  end  system  and  is 
not  related  to  interoperability. 

c.  Network  Laver.  While  tbe  MTS  broadcast  protocol  allocates  space  or  the  network  header,  it  is  not 
functional.  For  this  layer  only,  the  functionality  of  tbe  MTS  switched  protocol  will  be  compared  to  tbe  other 
protocols.  See  Table  A-2.  The  differences  are  listed  below. 

•  Message  Types.  In  the  VMF  and  AFS-BOM  protocols  tbe  message  type  field  defines  a  more 
expansive  list  of  message  types.  Tbe  same  division  of  SYSCON,  perishable,  a  noo-perish-able 
messages  remains,  however,  so  there  is  no  related  interoperability  problem. 

•  Routing.  VMF  and  AFS-BOM  both  allow  a  destination  source  list  to  be  present  in  the 
network  header.  MTS  switched  protocol  would  interpret  this  list  as  multiple  destinations  rather 
than  a  routing  list.  MTS,  VMF,  and  AFS-BOM  are  not  interoperable  when  more  than  one 
destination  address  is  present  in  the  header. 

•  Message  Segmenting.  MTS  (broadcast)  and  VMF  do  not  allow  a  message  to  be  segmented. 
AFS-BOM  segments  messages  over  3,500  bytes.  This  is  not  currently  a  problem  because  the 
broadcast  medium  allows  a  frame  size  of  3,500  bytes,  which  is  more  than  the  longest  message. 
Segmentation  is  not  necessary. 

•  Originator  and  Addressee.  The  MTS  uses  the  principle  of  a  3-byte  geographically  hierarchical 
address  or  fixed  addresses.  Tbe  description  of  its  use  is  difference  because  the  routing  function 
has  been  moved  from  tbe  switches  into  end  systems  in  tbe  broadcast  medium. 

d.  Transport  Laver.  There  are  not  functional  differences  among  the  protocols  in  this  layer. 


13  This  section  is  based  on  a  contribution  from  tbe  US  Marine  Corps,  Comparison  of  the  Marine  Tactical  System 
(MTS(,  Variable  Message  Format  (VMF),  and  Army  Fire  Support  Bit-Oriented  Message  (AFS-BOM)  Protocols, 
Draft,  MCRDAC/Integmion,  15  November  1991,  UNCLASSIFIED. 

1 4  Army  Hie  Support  Bit-Oriented  Message  (AFS-BOM)  Protocol,  US  Army  Field  Artillery  School.  1990. 
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Table  C-4.  Comparison  of  Protocol  Functions 


FUNCTIONS 

MTS 

VMF 

AFS 

amteit  \  rat 

Electrical 

Mechanical 

Functional 

Procedural 

Link  Laver 

Frame  Formatting 

Frame  Addressing 

Commands  and  Responses 

Media  Access 

Random 

Random  &  Prioritized 

Prioritized 

Conned  ion  Esiabishmem  &  Release 

One  XID  exchange 

2  new  XO  exchanges 

? 

Frame  Transfer 

Acknowledgement 

Verifies  dais  pattern 

Does  not  verity  data  pattern 

Does  not  verity  data  pattern 

Retransmission 

Error  Defection  &  Correction 

*  3  message  types 

9  message  types 

0  message  typea 

Header 

Routing 

*  Directory 

Diredory  &  Source 

Directory  &  Source 

Measage  Segmenting 

*  Yes 

none 

Yes 

Packet  Addressing 

* 

Packet  Precedence 

» 

Network  Flow  and  Cogestion  Control 

* 

End-to-End  Error  Recovery 

• 

Nul 

Session  Layer 

Message  Formatting 

Formal  3 

Format  3 

Format  1.2.  and  3 

Application  Laver 

Message  Header 

Different  M  interpretation  of 
massage  number  field 

Message  Acknowledgement 

System  Management 

• 

*  Function  is  present  in  the  MTS  switched  protocol,  but  not  in  the  MTS  broadcast  protocol. 
Blank  fields  indicate  that  all  of  the  protocols  implnmenl  the  function  the  same 


c.  Presentation  Laver.  MTS  and  VMF  only  allow  Type  3  VMF  message  format,  but  AFS-BOM  will  a 
also  allow  VMF  message  formats  of  Types  1  and  2.  AFS-BOM  will  not  send  Type  1  or  Type  2  message  either 
MTS  or  VMF  protocols,  so  this  layer  will  be  interoperable. 

f .  Application  Laver.  The  message  number  field  in  the  header  contains  a  different  data  element  structure 
in  each  of  the  protocols.  In  both  MTS  and  VMF,  message  number  is  17-bit  field  made  up  of  a  7-bit  functional  area 
element  and  a  10-bit  number  element.  MTS  interprets  the  functional  area  as  an  ASCII  character  and  VMF  as  a 
numeric.  AFS-BOM  divides  the  17-bit  message  number  field  into  a  3-bit  format  designator  element,  a  4-bit 
functional  area  clement  and  a  10-bit  number  clement.  AFS-BOM  will  zero  fill  the  3-bit  format  designator  element 
to  achieve  interoperability  with  VMF.  MTS  would  not  recognize  VMF  or  AFS-BOM  message  numbers. 
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«.  FRENCH  CC1S  INITIATIVES15 

tf.l  RITA  (RAmi  InUgrf  dc  Transmission  Aatomatiqac) 

RITA  is  a  tactical  integrated  communication  network  for  the  deployed  Army,  which  offers  the  following 
services  between  static  or  mobile  users: 

•  Telephony 

•  Telegraph  (with  encoding  facilities) 

•  Facsimile 

•  Data  transmission. 

This  system  is  being  improved  in  order  to  take  into  account  new  operational  needs.  In  particular,  new 
standardized  numeric  services  are  under  development  as  well  as  the  interconnection  with  other  networks  (PR4G, 
SOCRATE,  SYRACUSE). 

The  following  sapdards  are  implemented  at  the  interface  level: 

•  NATO  interconnection:  STANAG  4206, 4211, 4249.  and  X.75M 

•  ISDN  networks:  T2  interface  and  D  protocol. 

€.2  RITTER  (Sheas  Intfgrf  de  Transmission  de  I'Amit  de  Terre) 

The  aim  of  RITTER  is  to  meet  the  French  Army  strategic  telecommunication  needs  and  to  enable 
interoperability  with  other  national  networks  and  with  NATO  networks.  The  following  functionalities  are  offered: 

•  Telephonic  switching 

«  Data  transmission  (X.25) 

•  Hierarchically  organized  network  management. 

The  numeric  support  implements  the  CQR  standards,  and  X25  transmissions  cany  the  telegraphy  and  X400 
Military  MHS. 


6.3  SOCRATE 

The  aim  of  the  SOCRATE  project  is  to  build  an  inter-army  backbone  telecommunications  network, 
implementing  the  most  recent  numeric  technologies.  This  program  consists  of  a  fusion  of  RA90  and  RITTER 
programs  in  a  single  and  coordinated  realization.  SOCRATE  will  offer  services  that  include  the  following: 

•  Telephony 

•  Data  transmission 

•  MHS 

•  Telex 

•  Still  rod  moving  picture  transmission. 

SOCRATE  will  also  guarantee  the  communications  security.  It  will  provide  a  national  covered  network 
built  upon  an  ATM  multiservice  switching  system  that  is  based  upon  electro-magnetic  waves  and  fibre-optic 
sections.  Access  to  SOCRATE  will  be  accomplished  via  ATM,  ISDN,  and  X.25  protocols,  as  well  as  via  G703 
interface. 


4.4  SYRACUSE 

SYRACUSE  is  a  transit  network  composed  of  an  earth  component  ad  a  spatial  component  (satellite).  It 
enables  communications  between  armies  inside  the  area  covered  by  the  satellite,  using  telephony,  telegraphy,  and 
data  transmission  services. 

(.5  NTT  A  (Inter*  Army  Transit  Node) 

With  the  aim  of  improving  the  internetworking,  the  creation  of  a  inter-army  trash  node  ha  been  decided. 
The  NTLA  is  a  tmique  gateway  between  actual  or  future  networks  (see  Figure  C-8).  The  exchange  protocols  are  based 
upon  the  X.75  protocol. 


13  Based  on  [FR  MOD  1994],  February  1994. 
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/|\ 


MILITARY 

NETWORKS 

Figure  C-8.  French  Internetworking  Concept 

6.6.  RAMSES  and  TELEMAC 

RAMSES  and  TELEMAC  are  both  application-oriented  networks  which  use  the  inter-army 
telecommunication  networks  SYRACUSE  and  RETIAIRE  (X.25).  These  systems  offer  secure  services  for 
telephony,  data  transmission.  MHS  (X400)  and  picture  transfer. 

6.7  ENTAME 

ENTAME  is  a  French  secured  inter-army  message  handling  system  based  on  the  ACP 127  procedure.  The 
message  format  is  ADat-P3  conformant  ENTAME  uses  various  military  networks  (RTDM,  RETIN  AT,  RESEDA) 
and  the  TELEX  network. 
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APPENDIX  D 
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INTERNATIONAL  CIVIL  STANDARDS 
RELEVANT  TO  INFORMATION  SYSTEMS 

I.  081  Architecture  and  General  Standards 

II.  Layer  1:  Physical  Layer 

III.  Layer  2:  Dale  Link  Layer 

IV.  Layer  S:  Network  Layer 

.  Layer  e.  iranepon  Layer 

VI.  Layer  S:  taaalan  Layer 

VII.  Layer  8:  Presentation  Layer 

VIII.  Layer  7:  AppMoatlon  Layer 

IX.  Mleeehaneous  Standards 
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INTERNATIONAL  CIVIL  STANDARDS  RELEVANT  TO 
INFORMATION  SYSTEMS  BY  LAYER  OF  OSI  REFERENCE  MODEL1 


I.  OSI  ARCHITECTURE  AND  GENERAL  STANDARDS2 


A.  OSI  Basic  Rafaranca  Modal  and  Convention* 

B.  Wotk  Plana  and  Coonfnation  Agraamants 

C.  Formal  Dascription  Techniques  (FDTa) 

D.  Sacurity 

E.  OSI  Management 

F.  OSI  registration  Authoritias 

Q.  OSI  Conformance  Tasting 

H.  Taxonomy  and  Proflss 

I.  Modeling  Faeflitias 

J .  Opan  System  Environmant  (OSE)  and  Programming  Intarfacaa 


A.  OSI  BASIC  REFERENCE  MODEL  AND  CONVENTIONS: 


STANAG3  4250* 


ISO  7498* 


1SO/IEC  7498-1:1994 
ISO  7498-2* 

ISO  7498-3* 

ISOflEC  7498-4* 
WD7  7498-5 
ISOmt*8309« 
ISO/TR9575* 
ISOflEC  TR  10730* 

ISOflEC  10731* 
ISOflEC  TR  12178 
rru-Tsx.200 
ITU-TS  X.210:1988 
ITU-TS  X. 210: 1993 
ITU-TS  X.220  Rev  1 


NATO  Reference  Model  for  OSI 

Part  1-General  Description,  Draft,  Edition  2 
Part  2-Security,  Drift 
Part  3-Naming  and  Addressing.  Draft 
Part  4— Management,  Draft 

OSI  Reference  Model,  Part  1:  Baaic  Reference  Model,  General  Axpects  (X. 200: 1988) 
Cor4 1  Technical  Corrigendum  1 

AD3 1*  Connection leta-Mode  Transmission 

PD  AD6  2*  Multipeer  Data  Tranrmtraioo  (MPDT)  (impended) 

OSI  Reference  Model,  Part  1:  General  Aspects,  Edition  2  (X.200) 

OSI  Reference  Modal,  Part  2:  Security  Archilectnre  (XJOO) 

OSI  Reference  Model.  Pw  3:  Naming  and  Addressing  (X.650) 

OSI  Reference  Model.  Part  4:  Management  Framework  (X.700) 

OSI  Reference  Model,  Part  5:  Architecture  for  Multi-Peer  Cnmmmicatinpa 
Service  Conventioni  (X.210:1988) 

OSI  Routing  framework 
Tutorial  on  Naming  and  Addressing 

WDAM !  Amendment  1:  Directory  Names 

Conventions  for  Definitions  of  OSI  Services  (X  .2 10: 1993) 

User  Requirements  for  Systems  Supporting  Time-Critical  Communications 
Reference  Model:  Baric  Reference  Model  (ISOflEC  7498),  1988 
OSI  Layer  Service  Definition  Conventions  (ISO  8509),  1988 
Conventioni  for  Definitions  of  09  Services  (ISOflEC  10731),  Draft,  1993 
Use  of  X.200  Series  Protocols  in  CCITT  Modifications.  1993 


1  Baaed  on  the  following: 

a.  ISOflEC  JTCmC  21  Prognmmu  of  Work  [SC21  N  8082  1993] 

b.  September  1993  NOSIP  Strategy  [NATO  1993] 

c.  Private  communication  from  UK’s  Defence  Research  Agency  [DRA  1993] 

d.  Aditiooal  contributions  from  the  nations  participating  in  the  ATCCIS  PWG. 

2  The  symbol  *  is  used  throughout  this  appendix  to  identify  thorn  standards  included  in  the  September  1993  NOSIP 
Strategy. 

3  STANAG:  NATO  Standardization  Agreement 

4  Cor..  Technical  Corrigendum  to  ISO  standard. 

3  AD.  Addendum  for  ISO  standard. 

4  PD  AD  Propoeed  or  Preliminary  Draft  Addendum  to  ISO  standwd. 

WD  Working  Draft  for  ISO  (status  of  text  prior  to  being  <t  as  t  Committee  Draft). 

*  TR:  Technical  Report  for  ISO. 
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UNCLASSIFIED 


rru-Ts  x.650 
rru-Ts  x  700 

rru-Ts  x.800 


OSI,  Basic  Reference  Model.  Naming  and  Addressing  (ISO  7498-3).  1992 

Management  Framework  for  Open  Systems  Interconnection  (OSI)  for  CCTTT  Applications 
(ISO  7498-4).  1992 

Security  Architecture  for  Open  Systems  Interconnection  for  CCITT  Applications  (ISO  7498-2), 
1991 


Working  Papers  on  Reference  Models  and  Architecture 

SC21  SO- 99  Approved  Commentaries  on  the  Basic  Reference  Model  for  Open  Systems  Interconnection,  SC2I 

OSI  Reference  Model  Editor 


SC21  N  S934  Collection  of  Definitions  of  OSI  Vocabulary  (April  1991  Version),  Rapporteur  on  Q17:  OSI 

Vocabulary 

S('2l  N  6069  Proposed  New  WG6  Question  Q6/2  on  the  Relationship  Between  the  OSI  Upper  Layer  Architecture 

and  OOP 


SC21  N  6070 

SC21  N  6157 
SC21  N  6198 
SC21  N  6808 
SC21  N  6902 
SC21  N  7093 


Working  Draft  Answer  to  the  Proposed  WG6  Question  on  the  Architectural  Relationship  Between 
OSI  and  OOP 

Answer  to  CCTTT  SG  VII Q  23  on  OSI  Reference  Model  Regarding  ISDN 
Approved  Commentaries  on  the  OSI  Basic  Reference  Model 
Organization  of  Work  on  OSI  and  ODP  Architecture  UK  National  Body 
Liaison  Statement  to  SC21  on  Revision  of  the  OSI  Reference  Model 

Proposed  New  Question  Ql/68  on  the  Definition  of  the  Term  “Application -Process-Title”  in  the  OSI 
Reference  Model 


SC21  N  7094 

SC21  N  8265 
SC21  N  8266 
Working  Papers 
SC21  N  3711 
SC21  N  3906 

SC21  N  4681 
SC21  N  6197 
SC21  N  6793 

SC 21  N  6794 
SC21  N  6812 

SC21  N  6813 
SC21  N  6814 

SC  21  N  6948 

SC21  N  6961 
SC 21  N  7062 
SC  21  N  7063 
SC21  N  8003 
SC21  N  8267 
SC21  N  8384 


Draft  Answer  to  Ql/68  -  Definition  of  the  Term  “Application-Process-Title”  in  the  OSI  Reference 
Model 

Liaison  Statement  to  SC21  on  OSI  Service  Conventions,  TTU-TS  SG7,  October  1993 
Liaison  Statement  to  SC21  on  OSI  Reference  Model.  TTU-TS  SG7.  October  1993 
on  Multicasting  (Multipeer  Data  Transmission) 

Requirements  for  Multipeer  Data  Transmission 

Final  Report  to  SC2I  in  Florence  on  the  Reassessment  of  Project  JTC  1.21.9.1  on  Multipeer  Data 
Transmission 

User  Requirements  for  Multi-Party  Communications  (MPC).  Canada 

WG1  Position  on  the  Reactivation  of  Project  1.21.9.1  (Multi-Peer  Data  Transmission) 

Proposed  Mechanism  for  Soliciting  National  Body  Input  on  Multipecr/Multicast  Application 
Requirements 

Preliminary  Requirements  for  a  Multipecr  Data  Communication  Architecture 

Request  to  Apply  the  Procedures  for  the  Reactivation  of  the  Multi-Peer  Data  Transmission  Project 
(MPDT) 

Draft  Addendum  for  Multi-Peer  Data  Transmission  Project  (MPDT) 

Liaison  Statement  to  SC 21  on  Lower  Layer  Multicast  Work  SC6  Enhanced  Transport  Mechanisms 
Meeting 

Responses  to  the  Proposed  Mechanism  for  Soliciting  National  Body  Input  on  Multipeer/Multicast 

Application  Requirements 

SC21/WG1  Decision  on  MPDT  Reactivation 

Liaison  Statement  to  SC6  on  Multipeer  Data  Transmission 

Liaison  Statement  to  CCITT  SG  VII  on  Multipecr  Data  Transmission 

NP  on  Architecture  for  Multipeer  Data  Communications 

Liaison  Statement  to  SC21  on  OSI  Multicast  Architecture.  TTU-TS  SG7.  October  1993 

Liaison  Statement  to  SC21/WG1  on  Multi-Peer  Data  Transmission.  ISO/TC184/SC5/WG2, 

December  1993 


Working  Papers 

SC21  N  5110 

5C21  N  6158 
SC21  N  6159 
SC2I  N  7066 
SC 21  N  7067 
SC21  N  7991 

SC21  N  7992 

SC21  N  7993 
SC21  N  8005 


on  Quality  of  Service 

Call  to  National  Bodies  and  Liaison  Organizations  for  Contributions  on  Technical  Structure  of 

Quality  of  Service  (QOS)  Architecture 

Final  Answer  to  Ql/62  (Quality  of  Service  Architectural  Issues) 

Framework  on  Quality  of  Service 

Liaison  Statement  to  SC6  Concerning  Quality  of  Service  (QOS) 

Resulu  of  the  SC21/WG1  Meeting  on  Quality  of  Service 

Liaison  Statement  to  JTC1/SC18.  SC2S.  SC27,  SC29,  ISO/TC68,  ISO/TC46.  and  JTC1/WG3 
Concerning  Activity  on  Quality  of  Service,  SC21/WG1,  August  1993 

Liaison  Statement  to  ISO/TC184/SC3/WG2  Concerning  Activity  on  Quality  of  Service, 
SC2I/WGI.  August  1993 

Quality  of  Service  Framework,  second  working  draft 

Liaison  Statement  to  ITU-TS/SG7  (Q2/7,  Q19/7,  Q20/7)  on  Quality  of  Service,  SC21/WG1,  August 
1993 


9  SD:  Standing  Document  for  an  ISO  subcommittee 
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SC21NM29 
SC21  N  8030 
SC21N8262 
SC21  N  8263 

Working  Paper* 

SC21  N  6906 
SC21  N  8018 
SC21  N  8268 


Liaison  Statement  to  JTC1/SC6  oa  Quality  of  Service,  SC21/WG1,  Aognrt  1993 
Liaison  Statement  to  EWOS,  CIW.  and  AOW  on  Quality  of  Service,  SC21/WQ1,  August  1993 
Liaison  Statement  to  SC21  and  SG6  on  OSI  Quality  of  Service,  ITU-TS  SG7,  October  1993 
Liaison  Statement  to  SC21  end  SC6  on  OSI  Quality  of  Service  Framework  Specifications,  ITU-TS 
SG7,  October  1993 
oa  Protocol  Efflcioacy 

liaison  Statement  to  SC21  on  Efficiency  of  OSI  Protocols 

Liaison  Statement  to  ITU-TS  SG7  (Q19/7)  on  Ql/65.2 — OSI  Protocols  Efficiency,  August  1993 
Liaison  Statement  to  SC21  WGs  1  and  8  on  OS  Protocol  Efficiency  to  ICG  on  Satellite  Matters. 
SG8,  SGI  1,  SG13, 1  SO/I  EC  JTC1/SC21  (WGs  1  and  8).  and  ISO/JTC1/SG6,  ITU-TS  SG7,  October 
1993 


Working  Papers 
SC21N8004 

SC21  N  7090 

SC21  N  8382 

SC21  N  8383 

SC21  N  8383 


on  Time  Critical  Communications 

Liaison  Statement  to  ISO/TC 1 84/SC3/WG2  on  Question  63.1 — User  Reqniwsnenta  for  OSI  Systems 
Supporting  Time  Critical  Communications,  SC21/WG1,  August  1993 

Proposed  New  Question  Ql/63  on  User  Requirements  for  OSI  Systems  Supporting  Time  Critical 
Communications 

Liaison  Statement  to  SC21/WG4  on  Management  of  Time  Critical  Communications. 
ISCVTC  184/SC5/WG 2,  December  1993 

Liaison  Statement  to  SC21/WG1  on  Question  63.1 — User  Requirements  for  OSI  Systems 
Supporting  Tune  Critical  Communications,  ISCVTC  184/SC5/WG  2,  December  1993 
Final  Draft  Version  of  TCCA  Technical  Report  (DTR  12178)  Seat  to  the  ISO  Central  Secretariat  for 
Publication,  ISCVTC  184/SC5/WG 2.  December  .  1993 


Working  Papers — Time  Service 

SC21  N  6749  Proposal  for  a  New  Work  Item  on  Information  Technology  -  Text  Communication  -  Coordinated 

Time  Service  in  an  OSI  Environment 

SC21/WG4  N  1431  Comments  on  SC21  N  6749:  NP  Tune  Services  in  mi  OSIE 


B.  WORK  PLANS  AND  COORDINATION  AGREEMENTS: 


Standing  Docm 

SGFSSD-4 

SGFSSD-7 
SC2I  SD-1 
SC21  SD-2 

SC21  SD-3 
SC21  SD-4 
SC21SD-3 
SC21  SD-6 
SC21SD-7 
SC21SD-8 
SC21  SD-9 

SC21  SD-10 
SC21  SD-1 1 

Gnldance 


lents 

Framework  and  Taxonomy  of  International  Standardized  Profiles  -  Directory  of  ISPs  and  Profiles 
Contained  Therein,  SGFS  N  1049,  November  1993 

Issues  List  for  Future  Development  of  ISO/IEC  TR  10000,  SGFS  N  1023,  September  1993 
Report  of  the  SC 21  Secretariat,  SC21  Secretariat,  January  1993 

ISO/IEC  JTC1  SC21  Programme  of  Work  (POW)- Target  Date  Summary  for  All  Active  and  PuMisbed 

Projects,  SC21  Secretariat,  October  1993 

SC21  Inter-Project  Dependencies,  SC21  Secretariat,  May  1992 

SC21  Strategic  Plan,  January  1992 

Rules  to  be  Applied  in  the  SC21  Editing  Process,  November  1991 
Directives  for  the  Work  of  JTC1,  Edition  2, 1992 
Management  plan  for  Security,  Edition  1,  June  1990 
SC21  Schedule  of  Meetings,  June  1993  (SC21  N  8084] 

Approved  Commentaries  on  the  Basic  Reference  Modal  for  Open  System  Interconnection,  OSI 
Reference  Model  Editor,  November  1991 
SC21/FTU-TS  Collaborative  Projects,  September  1993 
Management  Guidelines  for  SC21,  December  1993  [SC21  N  8362] 


SC21  N  7213 
SC21  N  7489 

SC21  N  8116 
SC21  N  8080 
SC21  N  8132 
SC21  N  8024 
SC21  N  8249 

SC21  N  8410 
Reports  for  1994 
1TC1  N  2642  Rev. 


JTCI  N2775 


Management  Guidelines  for  SC21,  June  1992  (to  be  updated  in  accordance  with  SC2I  N  8122) 

Guide  for  ITU-TS  (COTT)  and  ISO/IEC  JTCI  Cooperation,  December  1992  (Annex  K  to  the  ISO/IEC 
JTCI  Directives,  JTCI  N  2119) 

Final  Steps  for  the  Editing  of  Standards  in  the  Case  of  Collaborative  Work  with  ITU-TS,  June  1993 
Guidelines  for  Conducting  Editing  Meetings  Using  Electronic  MriL  June  1993 
Identification  of  Versions  in  the  Foreword  of  a  Standard,  June  1993 
Programne  of  Work  of  ISO/IEC  JTC1/SC21/WG1,  June  1993 

Rules  of  Procedure  and  Working  Methods  of  the  ITU  Tetocommanif-ations  Standardization  Sacsoc  and 
Study  Group  Responsibility  and  Mandates,  ITU-TS,  Ocaobar  1993 
Methodology  and  Guidelines  for  foe  Development  of  Application  Layer  Protocols 
JTCI  Plenary  Meetings 

Calling  Notice  and  Draft  Agenda  for  the  First  Meeting  of  ISO/IEC  JTC1/SC21  Joint  Washing 
Group  9,  Corrected  Version,  SC21  Secretariat,  September  1993  (to  process  the  interpretation  of 
ISO/IEC  Ouida  25  for  Information  Technology  Testing  Laboratories  for  Software  and 
Communications  Testing  Services  [JTCI  N  2527]  and  produce  a  revision  for  Ketfcutwg  as  a  draft 
technical  report;  bald  30  November  to  2  December  1993  in  London) 

Summary  of  Voting  oa  Docemsot  JTCI  N  2621,  Proposal  for  s  New  Worit  hsm.  Conceptual  Schama 
Modelling  Facility.  Dtosmbsr  1993 
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UNCLASSIFIED 


JTCl  N  283S  Report  from  ISO/IEC  JTC1/SC21  Chairman  on  Activities  Related  to  Application  Program  Interfaces 

(APIs)  and  Modelling  Facilities  (MFs).  January  1994 
JTCl  N  2836  JTC1/SC21  Reports  on  Application  Program  Interfaces  (APIs),  January  1994 

JTCl  New  Work  Item  Proposals 

JTCl  N  960  Proposal  for  an  NWI  Management  Information  Register  and  Registration  Procedure  (in  June  1993, 

SC21  recommended  to  JTCl  that  the  project  be  cancelled  [SC21  N  7944]) 

JTCl  N  2246  Proposal  for  an  NWI:  Command  Sequencer  (comments  on  JTCl  ballot  were  resolved  by  SC 21  in 

June  1993  and  the  revised  NWI  proposal  forwarded  to  JTCl  for  consideration  [SC21  N  7943]) 

JTCl  N  2248  Proposal  for  an  NWI:  Enhancement  of  Directory  Operational  Security  (comments  on  JTCl  ballot 

were  resolved  by  SC21  in  June  1993  and  the  revised  NWI  proposal  forwarded  to  JTCl  for 
consideration  (SC21  N  7933])  (revisions  to  nine  parts  of  ISO  9594  and  possibly  one  new  part; 
WDs  expected  February  1994,  CDs  November  1994,  DISs  May  1995,  and  ISs  May  1996) 

JTCl  N  2249  Proposal  for  an  NWI:  Removal  of  Session  Layer  Serial  Number  Limitation  (comments  on  JTCl 

ballot  were  resolved  by  SC21  in  June  1993  and  the  revised  NWI  proposal  forwarded  to  JTCl  for 
consideration  [SC21  N  7985]) 

JTCl  N  2264  Proposal  for  an  NWI:  Extensions  to  ACSE  Covering  ASOs  and  ASO-Associations  (comments  on 

JTCl  ballot  [JTCl  N  2507]  were  resolved  by  SC21  by  revising  the  scope  of  work;  the  project  has 
been  added  to  SC21  program  of  work  [SC21  N  8076]) 

JTCl  N  2612  Proposal  for  an  NWI:  Open  Systems  Assessment  Methodology,  August  1993  (failed  to  qualify  for 

JTCl  program  of  work,  as  five  P-members  do  not  commit  to  active  participation  [JTCl  N  2773, 
December  1993]) 

JTCl  N  2620  Proposal  for  an  NWI:  Conformance  Testing  of  OSI  Protocols  Over  OSI  Services  Provided  by  Non- 

OSI  Protocols,  August  1993  [SC21  N  8011,  June  1993]  (failed  to  qualify  for  JTCl  program  of  work, 
as  five  P-members  do  not  commit  to  active  participation  [JTCl  N  2774,  December  1993]) 

JTCl  N  2621  Proposal  for  an  NWI:  Conceptual  Schema  Modelling  Facility,  August  1993  [SC21  N  8060,  June 

1993]  (balloting  ended  in  November  1993)  (WD  expected  July  1995,  CD  July  1996,  DIS  July  1997, 
and  IS  July  1998) 

JTCl  N  2760  Proposal  for  an  NWI:  Amendment  to  ISO/IEC  8473-1  Covering  Extensibility  and  Quality  of 

Service.  December  1993  [SC6  N  8518,  November  1993)  (balloting  ends  16  March  1994)  (PD AM  k> 
ISO/IEC  8473-1  expected  October  1993.  DAM  March  1994,  and  AM  November  1994) 

JTCl  N  2769  Proposal  for  an  NWI:  Extension  to  ISO/IEC  8072  for  Protection  Quality  of  Service,  December  1993 

[SC6  N  8560,  November  1993]  (balloting  ends  1  April  1994) 

JTCl  N  2801  Proposal  for  an  NWI:  ISO/IEC  7498-n.  Architecture  for  Multipeer  Communications  [SC21  N  8003] 

(balloting  ends  29  March  1994)  (new  part  to  ISO  7498;  WD  expected  in  1995,  CD  in  1996,  MS  in 
1997.  and  IS  in  1998) 

JTCl  N  2802  Proposal  for  an  NWI:  Enhancements  to  LOTOS.  December  1992  [SC2I  N  8022]  (balloting  ends  29 

March  1994)  (PDAM  to  ISO  8807  expected  June  1995,  DAM  June  1996.  and  AM  June  1997) 

JTCl  N  2803  Proposal  for  an  NWI:  Directory  Schema  Migration,  December  1992  [SC21  N  7942]  (balloting  ends 

29  March  1994)  (revisions  to  nine  parts  of  ISO  9594;  WDs  expected  July  1994,  CDs  November 
1994.  DISs  May  1995.  and  ISs  May  1996) 

Reports,  Resolutions,  and  Recommendations  from  SC21  Plenary  Meetings 

JTCl  N  2707  Proposed  Modifications  to  the  ISO/IEC  JTC1/SC21  Programme  of  Work,  Secretariat,  ISO/IEC 

JTC1/SC21,  November  1993 

JTCl  N  2777  Report  of  JTC1/SC21  to  the  1994  JTCl  Plenary  Meeting  in  Washington,  DC,  Secretariat.  ISO/IEC 

JTC1/SC21,  December  1993 

JTCl  N  2851  Management  Report  of  JTC1/SC21  to  the  1994  JTCl  Plenary  Meeting  in  Washington,  DC, 

Chairman.  ISO/IEC  JTC1/SC2I,  January  1994 

SC21  N  7978  Rationale  for  Proposed  SC21/WG4  Program  Extensions.  SC21/WG4,  July  1993 

SC 21  N  7979  Report  of  the  Tenth  ISO/IEC  JTC1/SC21/WG4  Meeting,  Yokohama,  15-24  June  1993,  SC21/WG4, 

September  1993 

SC21  N  8021  Report  of  the  ISO/IEC  JTC1/SC21/WG1  Meeting.  Yokohama,  16-24  June  1993,  SC21/WG1, 

September  1993 

SC21  N  8024  ISO/IEC  JTC1/SC21/WG1  Programme  of  Work.  SC21/WG1,  July  1993 

SC 21  N  8027  Resolutions  of  SC21/WG1.  June  1993 

SC21  N  8028  List  of  Late  Contributions  and  Output  Documents  of  the  SC21/WG1  Yokohama  Meeting. 

16-24  June  1993.  SC21/WG1.  July  1993 

SC21  N  8081  Resolutions  of  the  Ninth  Plenary  Meeting  of  ISO/IEC  JTCl /SC  21,  29-30  June  1993,  Yokohama. 

Japan,  June  1993 

SC2I  N  8123  Resolutions  of  SC21/WG3.  June  1993 

SC21  N  8217  Report  of  the  SC21/WG7  Meeting.  June  1993,  Yokohama,  SC2I/WG7,  September  1993 

SC21  N  7977  Resolutions  of  SC2I/WG4.  June  1993 

SC2I  N  8055  Resolutions  of  SC21/WC.7,  June  1993 

SC2I  N  8078  Resolutions  of  SC21/WG8.  June  1993 

SC21  N  8085  Convenor's  Report  for  SC21/WG1,  June  1993 

SC21  N  8115  Convenor’s  Report  for  SC21/WG3,  June  1993 
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SC21  N  tOO  Convener’!  Report  for  SC21/W04,  June  1993 

SC21  N  8124  Convenor's  Report  for  SC21/WG7,  Jane  1993 

SC21  N  1079  Convenor's  Report  for  SC21/WG8,  Jaw  1993 

KWOfi  Technical  G aides 

EWOS  SD17  Geoeric  Terms  of  Reference  for  EWOS  Expert  Groups,  November  1993 

EWOSETOOOl  FT  AM  -  Tutorial  on  Rules  for  ASN.l  Encoding,  April  1989 

EWOS  ETO  003  FT  AM  -  Remote  Actions  (RA)  over  FT  AM,  Service  end  protocol.  Edition  2,  May  1992 

EWOS  ETG  005  Introduction  to  Directory  Profiles,  Edition  3,  May  1993 

EWOS  ETC  007  FT  AM  -  Service  Classes  and  Functional  Units  in  ENV  41  205,  Edition  2,  August  1990 

EWOS  ETG  008  Procedures  and  Evaluation  Criteria  for  Standardization  of  Test  Specifications  for  European 

Functional  Standards,  October  1990 

EWOS  ETG  009  Conformance  Vocabulary,  Edition  2,  September  1992 

EWOS  ETG  010  Conformance  Tutorial,  January  1991 

EWOS  EIG011  Tutorial  for  Directory  Q-Profile  Production,  January  1991 

EWOS  ETG  013  A  Mapping  of  tbe  X-Window  System  over  an  OSI  Stack,  May  1991 

EWOS  ETG  016  PTS  Specification,  February  1992 

EWOS  ETG  017  Error  Hmdliag  in  Directory,  May  1992 

EWOS  ETG  018  OSI  TP  Tutorial.  Part  1,  September  1992  and  Part  2,  May  1993  (separate  volumes) 

EWOS  ETG  020  PTS  Maintenance  Procedures,  September  1992 

EWOS  ETG 022  Organization  of  Common  PTS,  November  1992 

EWOS  EIG  023  Tbe  TICN  Style  Guide  sod  Quality  Criteria,  November  1993 

EWOS  ETG  026  Role  of  Standards  in  OSI  Testing.  Edition  2,  February  1993 

EWOS  ETG  Q27  Security  Architecture  for  tbe  Directory,  February  1993 

EWOS  ETG  028  Interoperability  -  Vocabulary,  May  1993 

EWOS  ETG  029  Interoperability  -  Classification,  May  1993 

EWOS  EIG  xxx  Library  of  Test  Specifications,  Draft  (ETG  expected  November  1993) 

EWOS  ETG  xxx  Technical  Guide  to  ISO  9646  Test  Environment,  Draft  (ETG  expected  November  1993) 

EWOS  ETG  xxx  Interconnection  of  Directory  Domains  (DMD-DMD),  Draft  (ETG  expected  November  1993) 

EWOS  EIG  xxx  Methodology  Handbook  for  PTS  Production,  Draft  (replaces  ETG  008;  ETG  expected  February  1994) 

EWOS  ETG  xxx  Test  Report  Proformas,  Draft  (EIG  expected  February  1994) 

EWOS  ETG  xxx  Development  of  Taxonomy  for  DBE  Requirements,  Draft  (EIG  expected  Match  1994) 

EWOS  ETG  xxx  Technical  Frame  wort  for  Security-Related  Profile  Development.  Draft  (ETG  expected  May  1994) 
EWOS  ETG  xxx  Application  of  Security  Techniques  to  Base  Standards.  Draft  (ETG  expected  May  1994) 

EWOS  ETG  xxx  User  Requirements  for  More  DBE  Rrofilm,  Draft  (ETG  expected  September  1994) 

EWOS  ETG  xxx  Policy  Statement  on  the  Role  of  Standards  in  OSI  Testing.  Draft 

Regional  Workshop  Technical  Reporta 

RWS-TR  001  Guiding  Principals  for  Regional  Requirements 

RWS-TRxxx  Guidelines  for  Managed  Object  Profiling  and  Taxonomy  (EWOS),  November  1993  (RWS-TR 

expected  February  1994) 

RWS-TR  xxx  Framework  for  Conformance  Testing  of  Network  Management  Profiles  (EWOS)  September  1993 

(RWS-TR  expected  February  1994) 

RWS-TR  xxx  Registration  of  Object  Identifiers  in  ISPs  (EWOS  SD-16;  EWOS  approval  expected  March  1994) 

RWS-TR  xxx  Conformance  Testing  Vocabulary  (EWOS  approval  expected  May  1994) 

RWS-TR  xxx  TTCN  Style  Guide  (EWOS  approval  expected  November  1994) 

RWS-TR  xxx  Library  of  Test  Specifications  (EWOS  approval  expected  November  1994) 

RWS-TR  xxx  Guidelines  for  Managed  Object  Harmonization  (EWOS  approval  expected  November  1994) 

RWS-TR  xxx  Ensembles  Guidelines  (EWOS  approval  expected  November  1994) 

RWS-TR  xxx  Test  Case  Selection  Rules  (OIW) 

Other  Documents — SGFS 

SGFSN1003  Modification  of  SD- 1,  SGFS  Procedures,  for  Adoption  of  PTSa  and  APIs,  August  1993 

SGFS  N  1043  Liaison  Statement  to  SGFS  and  EWOS/EG-OSE,  OIW,  November  1993 

SGFS  N  1065  US  Comments  on  OIW  Liaison  Statement  to  SOPS  and  EWOS/EG-OSE,  August  1993 

SGFS  N  1087  Liaison  Statement  to  SC21/SWG-PS,  SOPS,  December  1993 

SGFS  N  1089  While  Paper  on  OSE  Profiling  Concepts,  SGFS.  December  1993  (materiel  offered  for  integration  in 

ISQrtEC  TR  10000) 

SOPS  N 1090  Liaison  Statement  to  JTC1  on  the  Subject  of  PAS  and  APIs,  December  1993 

SOPS  N  1099  Draft  Minutes  of  the  SOPS  Authorized  Subgroup  Meeting  in  Amsterdam,  29  November  to  3 

December  1993,  SOFS,  December  1993 

SGFS  N 1098  Resolutions  Adopted  by  tbe  SGFS  Authorized  Subgroup  Meeting  in  Anwterdsm,  29  November  to  3 

December  1993,  SOFS,  December  1993 

Other  Documents— SCO 

SCO  N  S13S  Draft  Statement  of  Expected  Benefits  Regarding  Category  C  Liaison  Between  the  Internet  Society 

rod  ISO/IEC  JTC1/SC6,  July  1993 
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UNCLASSIFIED 
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UNCLASSIFIED 


SC6  N  8419 
SC6  N  8420 

Other  Documents- 
SC21  N  5194 
SC21  N  5228 
SC21  N  5229 
SC21  N  5714 
SC21  N  6273 

SC21  N  6478 
SC21  N  6527 
SC21  N  6530 
SC21  N  6606 
SC21  N  6615 
SC21  N  6619 
SC21  N  6711 
SC21  N  6713 
SC21  N  6714 
SC21  N  6715 
SC21  N  6777 
SC21  N  6778 
SC21  N  6779 
SC21  N  6807 
SC21  N  6883 
SC2I  N  6905 
SC21  N  6907 

SC21  N  6943 
SC21  N  6943  Rev 

SC 21  N  6957 
SC  21  N  6966 

SC21  N  6969 
SC21  N  7099 
SC21  N  7101 
SC21  N  7132 
SC  21  N  7140 

SC21  N  7195 
SC21  N  7196 
SC21  N  7204  Rev 
SC 21  N  7205 
SC 21  N  7206 
SC21  N  7214 
SC21  N  7215 
SC21  N  7268 
SC21  N  7375 
SC21  N  7379 
SC2I  N  7713 
SC21  N  7720 
SC21  N  7728 
SC21  N  7747 
SC21  N  7749 
SC21  N  7841 

SC2I  N  7915 
SC21  N  7983 
SC21  N  8103  Rev. 
SC21  N  8122 
SC21  N  8034 


Appendix  D 


ISO/1EC  JTC1/SC6  Liaison  Contribution  to  the  Internet  Society.  November  1993 

Statement  of  Expected  Benefits  Resulting  from  Liaison  Between  ISO/IEC  JTC1/SC6  and  the  Internet 

Society,  November  1993 

-SC21 

Resolutions  of  the  Fourth  Plenary  Meeting  of  SC21.  5  June  1990,  Seoul 

Report  of  the  ISCWEC  JTC1/SC2I  Plenary  Meeting.  5  June  1990,  Seoul  Korea 

Report  of  the  JTC1/SC21  Plenary  Meeting.  5  June  1990,  Seoul,  Republic  of  Korea 

Resolutions  of  the  ISO/IEC  JTC1  Advisory  Group  Meeting,  Washington,  DC.,  19-21  February  1991 

Resolutions  of  the  Seventh  Plenary  Meeting  of  ISO/IEC  JTC1/SC21, 

4-5  June  1991,  Arles,  France 

Target  Dales  for  Completion  of  SC22  Projects 

Resolutions  of  the  ISO/IEC  JTC1  Plenary  Meeting,  October  2-4,  1991,  Madrid,  JTC'l  Secretariat 
Report  of  the  JTCI  Plenary  Ad  Hoc  Group  on  EDI 
Collection  of  Liaison  Statements  from  SC27  to  SC21 

The  Processing  of  Standards  in  SC21.  SC21  Special  Meeting  on  Structure  and  Organization 
Resolutions  of  the  SC21  Special  Meeting  on  Structure  and  Organization,  ANSI 
SC21  SD-4,  SC21  Strategic  Plan 

ITU-TS  Circular  No.  1 18  Regarding  the  Catalogue  of  CCITT  Recommendations 

List  of  Contact  Points  of  SIGs/EGs  of  Regional  Workshops 

Letter  from  ITTF/ITU-TS  Regarding  Preparation  of  CCT1T-ISO/IEC  Common  Text 

Letter  from  ISO  Regarding  the  Disbandment  of  GOST 

ITU-TS  Interim  Meeting  Schedule 

Statement  Regarding  Participation  at  CCITT  Study  Group  Meetings 
Protocol  Version  Numbers 

Report  of  the  Secretarial  to  the  SC21  Meeting  in  Ottawa 
Liaison  Statement  to  SC2I/WG6:  Report  on  Q26/VD  Meeting 

Liaison  Statement  to  SC21  Concerning  Collaborative  Work  on  ODP.  Security.  ASN.l,  ROSE,  and 
RISE 

Requirements  and  Recommendations  Regarding  Protocol  Version  Numbers 

Requirements  and  Proposed  Recommendations  of  the  Protocol  Version  Numbers  Pre-Meeting  (and 
the  Initial  ITTF  Response) 

Project  Dependencies 

Incorporation  of  Versions  and  Extensibility  Technical  Material  into  Existing  Standards  and  Other 
Documents 

Comments  on  SC21  N  6943,  Recommendations  and  Requirements  on  Protocol  Version  Numbers 
Resolutions  Approved  by  SC21/WG1  at  Its  Ottawa  Meeting 

List  of  Late  Input  Documents  and  Output  Documents  of  the  SC21/WG1  Ottawa  Meeting 
Request  for  National  Body  Comment  on  NWI  for  Library/Catalogue 

Reply  to  Liaison  Statement  for  CCITT  SG  VD  Regarding  the  Comments  on  Notatjonal  Tools  in 
SC21  N  6568,  9  July  1992 

SC21  Position  on  SC21  N  6484  “Guide  for  CCITT  and  JTCI  Collaboration” 

SC21  SD-  8.  SC21  Schedule  of  Meetings  SC21  Plenary  Meeting 

Resolutions  of  the  Eight  Plenary  Meeting  of  ISO/IEC  JTCI/SC21,  Revised 

ISO/IEC  JTC1/SC21  Programme  of  Work 

WG3  Recommendations.  ISO/IEC  JTC1/SC21/WG3,  Ottawa 

Rapporteur’s  Report  on  SC21  Strategic  Planning 

Revised  Management  Guidelines  for  ISO/IEC  JTC1/SC21 

Collection  of  Definitions  of  OSI  Vocabulary 

Call  for  Contributions  on  SC21/WG4  Title  and  Terms  of  Reference 

Liaison  Statement  to  SC21  on  OSI  Profile  Conformance  Requirements  in  TR  10000-1 

Resolutions  of  the  ISO/IEC  JTCI  Plenary  Meeting.  23-26  March  1993,  Berlin,  Germany 

Revised  Title  and  Scope  for  SC  21 

Proposals  for  Re-assessment  or  Cancellation  of  Specific  SC2I  Projects 
Revised  Text  of  the  Guide  for  CCITT  and  ISO/IEC  JTCI  Cooperation 
The  International  Telecommunication  Union  •  An  Overview 

Report  of  the  Ninth  Plenary  Meeting  of  ISO/IEC  JTC1/SC21  to  be  held  from  29-30  June  1993  in 
Yokohama,  Japan 

Liaison  Statement  to  SC6  in  Reply  to  SC6  N  7961  and  7614,  SC21/WG8,  August  1993 
Liaison  Statement  to  SC21/WG8  and  SC27  on  Future  Liaison  Activity,  SC2I/WG4,  August  1993 
Request  from  SC21  to  JTCI  Concerning  the  "Fast  Tracking”  of  the  PCTE  Document,  June  1993 
Management  Guidelines 

Liaison  Statement  to  the  Object  Management  Group.  SC21/WG7,  August  1993 
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UNCLASSIFIED 


SC21  N  80S! 

SC21  N  8128 
SC21  N  8129 
SC21  N  8130 

SC21  N  8131 
SC21  N  8193 
SC21  N  8231 

SC21  N  8261 
SC21  N  8318 
SC21/WG6  N  1152 


Resolutions  of  the  Ninth  Plenary  Mooting  of  ISO/IEC  JTC1/SC  21,  29-30  June  1993,  Yokohama, 
Japan 

Liaison  Statement  to  the  Internet  Society,  SC21,  June  1993 

Statement  of  Benefit*  on  Establishment  of  C -Liaison  with  X/Open,  SC21,  June  1993 

Statement  of  Benefits  on  Establishment  of  C-Liaiaon  with  the  Object  Management  Group  (OMG), 

SC21,  June  1993 

Statement  of  Benefits  on  Establishment  of  C-Liaiaon  with  the  Internet  Society,  SC21,  June  1993 
Status  of  X. Series  Recommendations,  ITU-TS  SG7,  August  1993 

Proposed  Approval  of  27  Recommendations  Agreed  to  by  Study  Group  7  at  its  Meeting  on  2  July 
1993,  ITU-TS,  October  1993 

Liaison  Between  SC24  and  SC21,  SC24,  October  1993 

Establishment  of  Formal  Liaison  Between  JTC1/SC21  and  JTC1/SC29,  SC 29,  December  1993 
Proposals  for  Changes  to  SC21/WG6  Programme  of  Work 


C.  FORMAL  DESCRIPTION  TECHNIQUES  (FDTs): 


ISO  8807 


ISO  9074 
WD9074.211 

ISQ/TR  10167* 
PDTR  11389 
PDTR  11590 
SC21  N  6088 

SC21  N  7096 
SC21  N  8022 
SC21  N  8023 
SC21  N  8122 
SC21  N  8280 

SC21/WG1  N  1157 
ITU-TS  Z.100  Rev  1 

rru-Tsz.no 

ITU-TS  Z.  120 


LOTOS  -  A  Formal  Description  Technique  Based  on  the  Temporal  Ordering  of  Observational 
Behaviour  (Z.100) 

AM10  1  Graphical  Representation  of  LOTOS  (G-LOTOS) 

WDAM  2  Enhancements  to  LOTOS 

Estelle  -  A  Formal  Description  Technique  Based  on  an  Extended  Stale  Transition  Model 
AM  1  Estelle  Tutorial 

Estelle  -  A  Formal  Description  Technique  Based  on  an  Extended  State  Transition  Model.  Edition  2 
(incorporates  AM  1) 

Guidelines  for  the  Application  of  Estelle,  LOTOS,  and  SIX.  (Z.110) 

LOTOS  Description  of  the  CCR  Service,  1993 
LOTOS  Description  of  the  CCR  Protocol,  1993 

Proposal  for  a  WG7  Question  on  the  Suitability  of  the  Formal  Description  Technique  Z  for  Use  in 
ODP 

Draft  Answer  to  Ql/48.6  -  G-LOTOS 
NP  on  Enhancements  to  LOTOS 

Initial  Draft  on  Enhancements  to  LOTOS,  SC21/WG1,  November  1993 

Update  to  Management  Guidelines  on  Formal  Descriptions.  SC21,  June  1993 

Liaison  Statement  to  SC21/WG4  on  Requirements  and  Directions  for  the  Use  of  Formal  Description 

Techniques  for  the  Specification  of  Managed  Objects,  ITU-TS  SG7,  October  1993 

Contributions  on  LOTOS  Enhancements 

Specification  and  Description  Language  (SDL) 

Criteria  for  the  Use  and  Applicability  of  Formal  Description  Techniques 
Messages  Sequence  Charts 


D.  SECURITY: 


Interconnection 
ISO  8372 
ISO/IEC  9160 
ISO/IEC  9796 
ISO/IEC  9797 

ISO/IEC  9798-1 
E»S  9798-2 

DIS  9798-3 

WD  9798-4 

WD9798-X 

ISO  9979 
ISO/IEC  10116 


Standards  for  Security : 

Modes  of  Operation  for  a  64-bit  Bloch  Cipher  Algorithm 
Physical  Layer  Interoperability  Requirements 
Digital  Signature  Scheme  Giving  Message  Recovery 

Data  Integrity  Mechanisms  Using  a  Cryptographic  Check  Functioo  Employing  a  Block  Cipher 
Algorithm 

Security  Techniques  -  Entity  Authentication  Mechanisms,  Part  1:  General  Model 

Security  Techniques  •  Entity  Authentication  Mechanisms.  Part  2:  Entity  Authentication  Using 

Symmetric  Techniques,  SC27/WG2,  1993 

Security  Techniques  -  Entity  Authentication  Mechanisms,  Part  3:  Entity  Authentication  Using  a 
Public  Key  Algorithm,  SC27/W02,  1993 

Security  Techniques  •  Entity  Authentication  Mechanisms,  Part  4:  Entity  Authentication  Using  Noo- 
Revertible  Functions,  SC27/WG2,  1993 

Security  Techniques  -  Entity  Authentication  Mechanisms,  Part  x:  Entity  Authentication  Using 

Zero-Knowledge  Techniques,  SC27/WG2,  1993 

Procedures  for  the  Registration  of  Cryptographic  Algorithms 

Modes  of  Operation  for  an  N-bit  Block  Cipher  Algorithm 


10  AM:  Amendment  to  ISO  stmdaid. 

1 1  For  ISO  standards,  the  decimal  indicates  the  version  number;  thus.  WD  9074.2  is  Van  ten  2  (no  decimal  indicate* 
Version  1). 
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UNCLASSIFIED 


UNCLASSIFIED 


D1S  lOt 18-1 
IMS  10118-2 

WD  10118-3 

WD  10118-4 

CD12  10181-1.2* 
ISQ/IEC  10181-2* 


DIS14  10181-3* 
DIS  10181-4* 
DIS  10181-3* 
DIS  10181-6* 
CD  10181-7.2* 
W>5  10181-8 
ISO/1EC  10736 

I  SO/I  EC  10745* 
DIS  11577* 

DIS  11586-1 
DIS  1 1586-2 

DIS  11586-3 

DIS  1 15864 
WD  11586-5 
WD  11586-6 
WD  11770-1 
CD  11770-2 
CD  II 770-3 
PDTR  13335-1 

WDTR  13335-2 

WDTR  13335-3 


rru-Ts  x.soo 


rru-Ts  x.802 

ITU-TSX.810 

rru-Ts  x.8u 
ITU-TSX812 
rru-Ts  x.8i3 

ITIJ-TS  X.814 
ITII-TSX.815 
rru-Ts  x  816 
rru-Ts  x.830 

ITU-TSX.831 

ITU-TS  X.832 


Security  Techniques  -  Hash  Functions.  Part  1:  General  Model,  SC27/WG2,  1993 

Security  Techniques  -  Hash  Functions.  Part  2:  Hashing  Operation  Using  Symmetric  Block-Cypher 

Algorithm.  SC27/WG2.  1993 

Security  Techniques  -  Hash  Functions.  Part  3:  Dedicated  Hash  Functions,  SC27/WG2,  SC27  N  223, 
1993 

Security  Techniques  -  Hash  Functions.  Pert  4:  Hash  Functions  Using  Modular  Arithmetic, 
SC27/WG2  N  21,  1993 

Security  Frameworks  in  Open  Systems.  Part  1:  Overview 

Security  Frameworks  in  Open  Systems.  Part  2:  Authentication  Framework  (passed  DIS  ballot  in 
October  1993) 

WDAM 1  1  Authentication  Elements 
Security  Frameworks  in  Open  Systems.  Part  3:  Access  Control  Framework 
Security  Frameworks  in  Open  Systems.  Part  4:  Non-Repudiation  Framework 
Security  Frameworks  in  Open  Systems.  Part  5:  Confidentiality  Framework 
Security  Frameworks  in  Open  Systems,  Part  6:  Integrity  Framework 
Security  Frameworks  in  Open  Systems.  Part  7:  Security  Audit  Framework 
Security  Frameworks  in  Open  Systems.  Part  8:  Key  Management 
Transport  Layer  Security  Protocol.  October  1993 

PDAM^l  Security  Association  Establishment  Protocol 
Upper  Layer  Security  Model 
Network  Layer  Security  Protocol 

Generic  Upper  Layers  Security  (GULS).  Part  1:  Overview,  Models  and  Notation  (X.830) 

Generic  Upper  Layers  Security  (GULS).  Part  2:  Security  Exchange  Service  Element  (SESE)  Service 
Definition  (X.831) 

Generic  Upper  Layers  Security  (GULS).  Part  3:  Security  Exchange  Service  Element  (SESE)  Protocol 
Specification  (X.832) 

Generic  Upper  Layers  Security  (GULS),  Part  4:  Protecting  Transfer  Syntax  Specification  (X.833) 
Generic  Upper  Layers  Security  (GULS).  Part  5:  PICS  Proforma  (X.834) 

Generic  Upper  Layers  Security  (GULS),  Part  6:  Protecting  Transfer  Syntax  -  PICS  Proforma  (X.835) 
Key  Management,  Part  1:  Framework 

Key  Management.  Part  2:  Key  Management  Mechanisms  Using  Symmetric  Techniques 
Key  Management,  Part  3:  Key  Management  Mechanisms  Using  Asymmetric  Techniques 
Security  Techniques  •  Guidelines  for  Management  of  Information  Technology  Security,  Part  1: 
Concepts  and  Models,  SC27/WG1.  1993 

Security  Techniques  •  Guidelines  for  Management  of  Information  Technology  Security,  Part  2: 
Managing  and  Planning,  SC27/WG1,  1993 

Security  Techniques  -  Guidelines  for  Management  of  Information  Technology  Security,  Part  3: 
Techniques,  SC27/WG1.  1993 

Security  Architecture  for  Open  Systems  Interconnection  for  CCfTT  Applications  (ISO  7498-2), 
1991 


Lower  Layers  Security  Model  (TR  13594),  Draft,  1993 

Security  Frameworks  in  Open  Systems:  Security  Authentication  Frameworks  Overview 
(ISO  18181-1),  Draft,  1993 
Security  Frameworks  in  Open  Systems: 

Security  Frameworks  in  Open  Systems: 

Security  Frameworks  in  Open  Systems: 

Security  Frameworks  in  Open  Systems: 

Security  Frameworks  in  Open  Systems: 

Security  Frameworks  in  Open  Systems: 

Generic  Upper  Layers  Security  •  Security  Eexcbange  Service  Element: 
notation  (ISO  11586-1),  Draft,  1993 
Generic  Upper  Layers  Security:  Security  Eexcbange  Service  Element  (SESE)  Service  Definition  (ISO 
11586-2),  Draft.  1993 

Generic  Upper  Layers  Security:  Security  Eexcbange  Service  Element  (SESE)  Protocol  Specification 
(ISO  11586-3),  Draft,  1993 


Authentication  Framework  (ISO  18181-2),  Draft,  1993 
Access  Control  Framework  (ISO  18181-3).  Draft,  1993 
Non-Repudiation  Framework  (ISO  181814),  Draft,  1993 
Confidentiality  Framework  (ISO  18181-5),  Draft.  1993 
Integrity  Framework  (ISO  18181-6),  Draft,  1993 
Security  Audit  Framework  (ISO  18181-7),  Draft,  1993 

Overview,  Model  and 


* 2  CD:  Committee  Draft  for  ISO  standard  (formerly  Draft  Proposal  (DP)]. 

*  3  WDAM:  Working  Draft  Amendment  to  an  ISO  Standard  (has  the  status  of  a  WD). 

* 4  DIS:  Draft  International  Standard  for  ISO. 

*  ®  WD:  Working  Draft  for  ISO  (status  of  text  prior  to  being  submitted  as  a  Committee  Draft). 

* PDAM  Proposed  Draft  Amendment  to  an  ISO  Standard  (has  the  status  of  a  CD). 
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UNCLASSIFIED 


rruTsx.*33 

rru-Ts  X.S34 

1TU-TS  X.835 

Other  Secarlty 
ISO  7816-1 

ISO  7816-2 

ISO  7816-3 

ISO  8730 

ISO  8731-1 

ISO  8731-2 

ISO  8732 
ISO  9807 

ISO  9364-1 

ISO  9564-2 

ISO/IEC  10126-1 

ISO/IEC  10126-2 

DiS  10173 
ISO/IEC  10202-1 

DIS  10202-2 

CD  10202-3 

ISO/IEC  10202-4 

CD  10202-3 

DIS  10202-6 

WD  10202-7 

DIS  11568-1 

ISO/IEC  11131 
DIS  11166-1 

DIS  11166-2 

DIS  11568-1 

DIS  11368-2 

DIS  11368-3 

WD  11368-5 

WD  11368-6 

WD  11368-7 


Geaeric  Upper  Layers  Security:  Protecting  Traatfe  Syntax  Specification  (ISO  11386-4),  Draft, 
1993 

Generic  Upper  Layers  Security:  Security  Eexchange  Service  Element  (SESE)  PICS  Proforma  (ISO 
11586-3),  Draft,  1993 

Geaeric  Upper  Layers  Security:  Security  Eexchange  Service  Element  (SESE)  Protecting  Transfer 
Syntax  PICS  Proforma  (ISO  11586-6),  Draft,  1993 

Standards: 

Identification  Cards  -  Identification  Cards  with  Contacts,  Part  1:  Physical  Characteristics, 
SC17/WG4 

Identification  Cards  -  Identification  Cards  with  Contacts,  Part  2:  Number  and  Position  of  Contacts. 
SC17/WG4 

Identification  Cards  •  Identification  Cards  with  Contacts,  Part  3:  Electronic  Signals/Exchange 
Protocols,  SC17/WG4 

Financial  Transactions  -  Wholesale  Banking  Security  -  Requirements  for  Message  Authentication. 
TC68/SC2 

Financial  Transactions  -  Wholesale  Banking  Security  -  Approved  Algorithms  for  Message 
Authentication,  Part  1:  DEA-1  Algorithm,  TC68/SC2 

Financial  Transactions  -  Wholesale  Banking  Security  -  Approved  Algorithms  for  Message 

Authentication,  Part  2:  Message  Authenication  Algorithm,  TC68/SC2 

Financial  Transactions  -  Wholesale  Banking  Security  -  Key  Management,  TC68/SC6 

Financial  Transactions  -  Retail  Banking  Security  -  Requirements  for  Message  Authentication, 

TC68/SC6/WG6 

Financial  Transactions  -  Retail  Banking  Security  -  Personal  Identification  Number  (PIN) 
Management  and  Security,  Part  1:  PIN  Protection  Principles  and  Techniquea,  TC68/SC6/WG6 
Financial  Transactions  -  Retail  Banking  Security  -  Personal  Identification  Number  (PIN) 
Management  and  Security,  Part  2:  Approved  Algorithms  for  PIN  Encipherment,  7C68/SC6/WG6 
Financial  Transactions  -  Wholesale  Banking  Security  -  Procedures  for  Message  Encipherment,  Part 
1:  Genera]  Principles,  TC68/SC2,  1993 

Financial  Transactions  -  Wholesale  Banking  Security  -  Procedures  for  Message  Encipherment,  Part 
2:  DEA-  Algorithms.  TC68/SC2,  1993 

Text  and  Office  Systems  -  Document  Printing  Applicaion  (DPA),  SC18/WG4 

Financial  Transactions  -  Security  Architecture  •  Security  Architecture  of  Integrated  Circuit  Cards 

(ICCs).  Part  1:  Card  Life  Cycle  TC68/SC6/WG7. 1993 

Financial  Transactions  •  Security  Architecture  -  Security  Architecture  of  Integrated  Circuit  Cards 
(ICCs).  Part  1:  Transaction  Process.  TC68/SC6/WG7,  1993 

Financial  Transactions  -  Security  Architecture  -  Security  Architecture  of  Integrated  Circuit  Cards 
(ICCs).  Part  1:  Cryptographic  Key  Relationship,  TC68/SC6/WG7.  1993 

Financial  Transactions  -  Security  Architecture  -  Security  Architecture  of  Integrated  Circuit  Cards 
(ICCs).  Part  1:  Secure  Application  Modules,  7C68/SC6/WG7.  1993 

Financial  Transactions  •  Security  Architecture  -  Security  Architecture  of  Integrated  Circuit  Cards 
(ICCs).  Part  1:  Use  of  Algorithms,  TC68/SC6/WG7.  1993 

Financial  Transactions  -  Security  Architecture  -  Security  Architecture  of  Integrated  Circuit  Cards 
(ICCs).  Part  1:  Cardholder  Verification.  TC6S/SC6/WG7,  1993 

Financial  Transactions  -  Security  Architecture  •  Security  Architecture  of  Integrated  Circuit  Cards 
(ICCs).  Part  1:  Key  Management,  TC68/SC6/WG7,  1993 

Financial  Transactions  -  Retail  Banking  Security  •  Key  Management,  Part  1:  Introduction  to  Key 
Management,  TC68/SC6/WG6.  1993 

Financial  Transactions  -  Wholesale  Banking  Security  -  Sign-On  Autbcmticatioa,  TC68/SC2,  1993 

Financial  Transactions  -  Wholesale  Banking  Security  -  Key  Management  by  Means  of  Asymmetric 

Algorithms,  Part  1:  Principles,  Procedures,  and  Formats,  TC68/SC2,  1993 

Financial  Transactions  -  Wholesale  Banking  Security  -  Key  Management  by  Means  of  Asymmetric 

Algorithms,  Part  2:  Approved  Algorithms  Using  RSA  Cryptosystem,  TC68/SC2,  1993 

Financial  Transactions  -  Retail  Banking  Security  -  Key  Management,  Part  1:  Introduction  to  Key 

Management,  TC68/SC6/WG6,  1993 

Financial  Transactions  •  Retail  Banking  Security  •  Key  Management,  Part  2:  Key  Management 
Techniques  for  Symmetric  Ciphers,  TC68/SC6/WG6,  1993 

Financial  Transactions  -  Retail  Banking  Security  •  Key  Management,  Part  3:  Key  Life  Cycle  for 
Symmetric  Ciphers,  TC68/SC6/WG6,  1993 

Financial  Transactions  -  Retail  Banking  Security  •  Key  Management,  Part  5:  Key  Management 
Techniques  for  Asymmetric  Ciphers,  TC68/SC6/WG6,  1993 

Financial  Transactions  •  Retail  Banking  Security  •  Key  Management,  Part  6:  Key  Life  Cycle  for 
Asymmetric  Ciphers,  TC68/SC6/WG6,  1993 

Financial  Transactions  -  Retail  Banking  Security  -  Key  Management,  Part  7:  Key  Management 
Schemes,  TC68/SC6/WG6,  1993 
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CD  11568-8 

WD  13182 
CD  13492 

Working  Papers 

SC6  N  7951 
SC6  N  7952 
SC18  N  2233 
SC2I  N  8020 
SC21  N  8269 
SC21  N  8325 

SC21  N  8326 

SC21  N  8327 

SC21  N  8328 

SC21  N  8329 

SC21  N  8380 
SC21  N  3283 
SC21  N  4833 
SC21  N  4835 
SC21  N  4836 
SC21  N  5580 
SC21  N  5581 
SC21  N  5731 
SC2I  N  6586 
SC21  N  6695 

SC21  N  6656 
SC21  N  6755 
SC21  N  6765 
SC21  N  6843 
SC21  N  6844 
SC21  N  6875 
SC21  N  6877 
SC21  N  6878 

SC21  N  6893 
SC21  N  6974 

SC21  N  6996 
SC2I  N  6997 
SC21  N  6998 
SC2I  N  7085 
SC21  N  7087 
SC21  N  7089 
SC21  N  7098 
SC21  N  7134 
SC21  N  7145 

SC21  N  7149 
SC21  N  7292 
SC2I  N  7914 
SC21  N  8330 

SC2I  N  8380 
SC21/WG6  N  1123 
SC21/WG6N  1124 
SC21/WG6  N  1158 


Financial  Transactions  -  Retail  Banking  Security  -  Key  Management,  Part  8:  Key  Managementg 
Related  Data  Elements.  TC68/SC6/WG6.  1993 

Financial  Transactions  -  Security  Architecture  -  System  Overview,  TC68/SC6/WG7,  1993 
Financial  Transactions  -  Retail  Banking  Security  -  Secure  Cryptographic  Devices,  TC68/SC6/WG6, 
1993 

on  Security: 

OS1  Lower  Layer  Security  Model.  SC6/WG5,  1993 
Lower  Layer  Security  Guidelines,  SC6/WG5.  1993 
User  Requirements  for  Security  in  Text  and  Office  Systems 

Liaison  Statement  to  JTC1/SC27  on  Open  Systems  Security,  SC21/WG1,  August  1993 
Liaison  Statement  to  SC2i  WG/8  on  Security  Activities,  ITU-TS  SG7,  October  1993 
Authentication  and  Privilege  Attribute  Security  Application  with  Related  Key  Distribution 
Functions,  Part  1:  Overview  and  Functional  Model,  ECMA/TC-TG9,  November  1993 
Authentication  and  Privilege  Attribute  Security  Application  with  Related  Key  Distribution 
Functions.  Part  2:  Security  Information  Objects,  ECMA/TC-TG9,  November  1993 
Authentication  and  Privilege  Attribute  Security  Application  with  Related  Key  Distribution 
Functions.  Part  3:  Service  Definitions.  ECMA/TC-TG9,  November  1993 

Liaison  Statement  to  SC21/WG8  Regarding  Authentication  and  Related  Security  Services  for 
Distributed  Applications.  ECMA/TC-TG9.  November  1993 

Liaison  Contribution  to  SC21/WG8  Regarding  Authentication  and  Related  Security  Services  for 

Distributed  Applications  -  Extended  Schematic  for  First  Draft,  ECMA/TC-TG9,  November  1993 

Guide  to  Open  System  Security,  Working  Draft  Technical  Report,  December  1993 

Working  Draft  for  Lower-Layer  Security  Model 

Repcrt  to  JTC1  from  SC27  on  Security  Techniques,  SC27  Secretariat 

Report  of  the  First  Plenary  Meeting  of  SC27  at  Stockholm,  24-26  April  1990,  SC27  Secretariat 
Resolutions  Taken  at  the  First  Plenary  Meeting  of  SC27  at  Stockholm,  24-26  April  1990 
New  Area  of  Work  for  SC27/WG1  on  IT  Security  Information  Objects 
New  Area  of  Work  for  SC27/WG 1  on  IT  Security  Terminology 
Progression  of  the  Upper  Layers  Security  Standards,  Canada 

Meeting  Report  -  Collaborative  CCITT  Q19/VH  and  SC21/WG6  Meeting  on  Upper  Layers  Security 
Liaison  Statement  from  SC21/WGI  Security  Ad  Hoc  Group  to  SC21/WG5  TP  on  Preliminary 
Security  Model 

Liaison  Statement  to  SC21/WG6  on  Compatibility  of  ROS  and  RPC 
Contribution  on  Key  Management 

Guide  to  Open  Systems  Security  Collaborative  SC21/ITU-TS  Security  Ad  Hoc  Group  Meeting 
Contribution  on  Non-Repudiation  Framework 
Contribution  on  Security  Frameworks  Overview 

Liaison  Statement  to  SC21  from  SC18  on  "Revised  Draft  Guide  to  Open  Systems  Security” 

Liaison  Statement  to  SC21  from  SC  18  on  Security  Framework  SC18 

Liaison  Statement  to  CCITT  Q19/VB  and  SC21/WG6  from  SC18  on  Use  of  the  Security  Exchange 
ASE 

Liaison  Statement  to  SC21  on  Approval  of  Management  Framework 

Liaison  Statement  to  SC6  Concerning  a  Request  for  Incorporation  of  New  Protocol  Information 
Attributes  in  ISO/IEC  9594-6/DAM  I 

Liaison  Statement  to  SC6  on  Common  Aspects  of  OSI  Upper/Lower  Layer  Security  Standards 

Liaison  Statement  to  ECMA  on  Security  in  the  Upper  Layers 

Authentication  and  Related  Security  Services  for  Distributed  Applications 

Liaison  Statement  to  SC  1 8  on  Security 

Liaison  Statement  to  SC27  on  Security 

Statement  on  Scope  and  Usability  of  the  Open  Systems  Security  Framework 
Proposed  New  Question  QI/69  on  Conformance  Assessments  for  OSI  Security 
Preliminary  Document  on  Multiple  Input  Metric  Object 

Liaison  Statement  to  SC2I/WG1,  SC21/WG6  (8),  SC6  and  SC27  on  Security  Requirements  for 
Systems  Management 

Liaison  Statement  to  SC18  Regarding  the  Status  of  the  Security  Exchange  Work 
Guide  for  Open  Systems  Security 

Working  Document  on  Authentication  and  Related  Security  Services 

Version  V2  of  the  APA-Application  Standard,  ECMA/TC-TC9,  November  1993  (standard  has  three 
parts:  Overview  and  Functional  Model.  Security  Information  Objects,  and  Service  Definitions) 
Guide  to  Open  Systems  Security 

UK  Position  on  Alignment  of  Upper  and  Lower  Layer  Security  Protocols 

UK  Comment  on  SC21  N  6130,  Generic  Transfer  Syntax  Providing  Upper  Layers  Security 

Strawman  Generic  Security  ESO-OSI  Abstract  Interface 
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SC21/WG8  N  173  Authentication  and  Related  Security  Services.  Part  2.  Generic  Abstract  Services  for  Security 
(GASS),  Strawman 

SC22/WG15  N  46  Rev.  Security  Interface  for  POSIX,  SC22/WG15,  1993  (approved  new  work  item) 

SC27  N  209  Non-Repudiation  Mechanisms  (Part  1:  General  Model;  Part  2:  Mechsniimi  Using  Symmetric  Key 

Techniques;  and  Part  3:  Mechanisms  Using  Asymmetric  Techniques),  SC27/WG2 

SC27  N  467  Collection  and  Analysis  of  Requirements  for  Information  Technology  Security  Criteria,  SC27/WG3 

SC27  N  685  Security  Information  Objects,  SC27/WG1,  1993 

SC27  N  691  Guidelines  on  the  Use  and  Selection  of  Security  Services  and  Mechanisms  for  the  Management  of 

Trusted  Third  Party  Services,  SC27/WG1,  1993 

SC27  N  697  Glossary  of  Information  Technology  Security  Definitions,  SC27/WG1,  1993  (SC27  standing 

document) 

SC27  N  718  Evaluation  Criteria  for  Information  Technology  Security,  Part  2:  Introduction  and  Model, 

SC27/WG3,  1993 

SC27  N  721  Evaluation  Criteria  for  Information  Technology  Security,  Part  3:  Functionality  of  IT  Systems, 

SC27/WG3,  1993 

SC27  N  734  Evaluation  Criteria  for  Information  Technology  Security,  Part  1:  Assurance  of  IT  Systems, 

SC27/WG3,  1993 

SC27  N  791  Security  Incident  Reporting;  WG1  Meeting  No.  7;  12-15  October  1993  in  Paris,  SC27/WG1, 

November  1993 

E.  OSI  MANAGEMENT: 

STANAG  4407*  System  Management,  Draft,  NATO  UNCLASSIFIED  (cf.  ISO  10165-1,  10165-2.  10165-4,  10164, 
11183,  12059,  12060) 

Main  Body,  Preliminary  Draft 

Annex  A— Security  of  Management  (under  development) 

Annex  B — Military  Features,  Preliminary  Draft 

Annex  C — The  Development  of  NSPs  for  Systems  Management,  Preliminary  Draft 
Annex  D — NSP  rm-  Basic  Systems  Management,  Preliminary  Draft  (STANAG  4407-1) 

ISO/IEC  9595*  Common  Management  Information  Service  (CMIS)  Definition  (X. 710:1991) 

DAM  3  Support  of  Allomorphism 

AM  4  Access  Control 

WDAM5  Enhanced  Functionality 

Cor  1-2  Technical  Corrigenda  1-2 

ISO/IEC  9596-1  Common  Management  Information  Protocol  (CMIP)  Specification  (X.71 1:1991) 

PDAM  3  Support  of  Allomorphism 

PDAM4  State  Table17 

WDAM3  Enhanced  Functionality 

Cor  1-4  Technical  Corrigenda  1-4 

ISCVIEC  9596-2  Common  Management  Information  Protocol  (CMIP)  Specification,  Part  2:  PICS  Proforma  (X.712) 

Cor  1  Technical  Corrigendum  1 

ISO/IEC  10040*  Systems  Management  Overview  (X.701) 

AM  1  Management  Knowledge  Management  Architecture 

PDAM  2  Management  Domains  Architecture 

Cor  1  Draft  Technical  Corrigendum  1 

ISO/IEC  10164-1*  Systems  Management,  Part  1:  Object  Management  Function  (X.730) 

DAM18  1  ICS  Proforma 

ISO/IEC  10164-2*  Systems  Management,  Part  2:  State  Management  Function  (X.731) 

DAM  1  ICS  Proforma 

ISO/IEC  10164-3*  Systems  Management,  Part  3:  Attributes  for  Representing  Relationship  (X.732) 

DAM  1  ICS  Proforma 

ISO/IEC  10164-4*  Systems  Management,  Part  4:  Alarm  Repotting  Function  (X.733) 

DAM  1  ICS  Proforma 

ISO/IEC  10164-5*  Systems  Management,  Part  5:  Event  Report  Management  Function  (X.734) 

DAM  1  ICS  Proforma 

PDAM  2  Enhanced  Discriminator 

ISO/IEC  10164-6*  Systems  Management,  Part  6:  Log  Control  Function  (X.735) 

DAM  1  ICS  Proforma 

PDAM  2  Enhanced  Log 

17  Wort  on  a  PDAM  for  Stale  Table  to  ISO  9596-1  was  cmcelled  in  June  1991. 

18  DAM:  Draft  Amendment  for  an  ISO  standard  (has  the  stains  of  a  MS). 
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UNCLASSIFIED 


UNCLASSIFIED 


ISO/IEC  10164-7* 

ISO/IEC  10164-8* 

ISO/IEC  10164-9* 
DIS  10164-10.2 

ISO/IEC  10164-11* 

ISO/IEC  10164-12* 
ISO/IEC  10164-13* 


DIS  10164-14.2 
DIS  10164-15 
CD  10164-16.2 
CD  10164-17 

CD  10164-19 

WD  10164 -ev. 2 
WD  10164-mo 
WD  10164-nn.2 
WD  10164-rtm 
WD  10164-sw 
WD  10164-tm.2 
ISO/IEC  1016S-I* 


ISO/IEC  10165-2* 


ISO/IEC  10165-4* 


ISO/IEC  10165-5* 
ISO/IEC  10165-6* 


WD  10165-7.2* 

WD  10165-x 
ISO/IEC  10733 
DIS  10742 

SGFS  N  1076 

SC21  N  4077 
SC 21  N  4085 
SC21  N  4091 
SC21  N  4970 
SC21  N  6037 
SC21  N  6194 
SC 21  N  6306 
SC21  N  6799 
SC2I  N  6870 


Systems  Management.  Part  7:  Security  Alarm  Reporting  Function  (X.736) 

DAM  1  ICS  Proforma 

Systems  Management.  Part  8:  Security  Audit  Trail  Function  (X.740) 

Cor  1  Technical  Corrigendum  1.  January  1994 

Systems  Management,  Part  9:  Objects  and  Attributes  for  Access  Control 
Systems  Management.  Part  10:  Usage  Metering  Function  (X.742) 

WDAM  1  ICS  Proforma 

Systems  Management,  Part  1 1:  Metric  Objects  and  Attributes  (X.739) 

WDAM  1  ICS  Proforma 

WDAM  2  Additional  Metric  Objects  and  Attributes 

Systems  Management.  Part  12:  Test  Management  Function  (X.74S) 

PDAM  1  ICS  Proforma 

Systems  Management.  Part  13:  Measurement  Summarization  Function  (X.738) 

WDAM  1  ICS  Proforma 

WDAM  2  Additional  Summarization  Scanners 

Systems  Management,  Part  14:  Confidence  and  Diagnostic  Test  Categories 
Systems  Management,  Part  15:  Scheduling  Function 

Systems  Management,  Part  16:  Working  Ifecument  on  Management  Knowledge  Management 
Systems  Management,  Part  17:  Change  Over  Function 
WDAM  1  General  Relationship  Model 

Systems  Management,  Part  19:  Management  Domain  and  Management  Policy  Management 
Function 

Systems  Management.  Part  ev:  Enhanced  Event  Control  Function 

Systems  Management,  Part  mo:  Managed  Objects  for  Supporting  Upper  Layers,  January  1994 
Systems  Management.  Part  rm:  General  Relationship  Management  Function 
Systems  Management,  Part  rtm:  Response  Time  Monitoring  Function 
Systems  Management,  Part  sw:  Software  Management  Function 
Systems  Management,  Part  tm:  Tune  Management  Function 

Structure  of  Management  Information,  Part  1:  Management  Information  Model  (X.720) 

PDAM  1  Generalization  of  Terms 

Cor  1  Technical  Corrigendum 

Structure  of  Management  Information,  Part  2:  Definition  of  Management  Information  (X.721) 
PDAM  1  Enhanced  Discriminator  and  Log 
Cor  1  Draft  Technical  Corrigendum 

Structure  of  Management  Information,  Part  4:  Guidelines  for  the  Definition  of  Managed  Objects 
(X.722) 

PDAM  1  GDMO  Extensions 

PDAM  2  Set  By  Create  and  Component  Registration 
Structure  of  Management  Information,  Part  5:  Generic  Management  Information  (X.723) 

Structure  of  Management  Information,  Part  6:  Requirements  and  Guidelines  for  Management 
Information  Conformance  Statement  (MICS)  Proformas  (X.724) 

WDAM  1  Manager  Role  Conformance 

Cor  1  Draft  Technical  Corrigendum,  January  1994 

Structure  of  Management  Information,  Part  7:  Management  Information  Register  and  Registration 
Procedures 

Structure  of  Management  Information,  Part  x:  Management  Information  in  the  Upper  Layers 
Elements  of  Management  Information  Related  to  OSI  Network  Layer  Standards 
Specification  of  the  Elements  of  Management  Information  Related  to  OSI  Data  Link  Layer 
Standards.  1993 

Liaison  from  AOW/EWOS/OIW  to  SGFS  on  Submission  of  AOM  2x  Taxonomy,  SGFS,  December 
1993 

Fault  Management  Working  Document 
Accounting  Management  Working  Document 
OSI  Security  Management  Working  Document 
Systems  Management  Tutorial  -  Annex  A:  Access  Control 
Need  for  Security  Services  with  OSI  Management 

Final  Answer  to  Q  1/63.1 -Meaning  of  Conformance  to  Objects  in  the  Context  of  OSI  Management 
Performance  Management  Working  Document 
Contribution  on  Upper  Layer  Management 

Proposal  for  a  New  Work  Item  on  Mapping  of  the  OSI  System  Management  •  Object  Management 
Function  onto  Message  Oriented  Text  Interchange  System  (MOTIS) 
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SCSI  N  <914  Liaison  Statement  to  SC21:  Request  for  Review  ft  Comment  oo  Profile  Choices  for  Snbclseses  of 

the  EFD/LOG  Managed  Object  Classes  Using  Allomorphism  ft  Best  Efforts  Management  EWOS  for 
Regional  Workshop  Network  Management  Coordination  Com. 

SC21  N  6915  liaison  Statement  to  SC21  Regarding  Profiles  for  Systems  Management  Functions 

SC21  N  6968  Request  for  Comment  oo  Issues  Concerning  Upper  Layer  Management 

SC21  N  7091  Liaison  Statements  to  SC18  on  Quality  of  Service 

SC21  N  7105  Reply  and  Disposition  of  Comments  on  NP  on  Development  of  Enhanced  Functionality  for  CM1S/P 

(JTC1  N  1667).  ISO/IEC  JTC1/SC21/WG4  Meeting 
SC21  N  7106  Agreed  Requirements  for  Enhanced  Functionality  for  SM  Communications 

SC21  N  7107  NP  oo  Disposition  of  Ballot  Comments  on  JTC1  N  1439,  Proposal  for  an  Enhanced  Event  Handling 

ft  Log  Control 

rnmnwvt  Sequencer  for  Systems  Management 

Request  for  National  Body  Input  on  Principles  of  Conformance  for  Managing  Systems 
Management  Domains  Architecture 
Management  Domain  Management  Function 

Working  Draft  on  Application  Context  for  Systems  Management  with  TP 
General  Relationship  Model-Third  Working  Draft 

Request  for  National  Body  Contributions  to  Progress  Work  on  Distributed  Management 
Request  for  National  Body  Input  Regarding  Definition  of  Common  Terms  and  Use  of  Formal 
Description  Techniques  in  SMI  Standards 
SC21  N  7132  Preliminary  Document  on  Multiple  Input  Metric  Object 

SC21  N  7133  Coherence  of  Extended  Management  Architecture 

SC21  N  7134  Request  for  National  Body  Comment  on  NP  for  Library /Catalog 

SC21  N  7135  Call  for  Contributions  on  Priority  Mechanisms  in  Systems  Management 

SC21  N  7146  Liaison  Statement  to  SC22/WG1S  on  Software  Management 

SC21N7147  Liaison  Statement  to  COTT  Q23/IV  on  Softwwe  MO 

SC21  N  7148  Response  to  the  SC6  Liaison  Statement  on  Event  Definition 

SC21  N  7483  Proposal  for  a  New  Work  Item  on  Mapping  of  OSI  System  Management  -  Object  Management 

Function  onto  Message  Handling  Service  (MHS) 

SC21  N  7955  SC21/WG4  Standing  Document  1:  Issues  for  Extended  Systems  Management  Architecture,  July 

1993 

SC21  N  7957  Extended  Systems  Management  Architecture 

SC21  N  7959  Expiry  Behavior 

SC21  N  7962  Working  Document  for  Command  Sequencer  for  Systems  Management 

SC21  N  7965  Definition  of  Systems  Management  Protocol  Machine  Managed  Objects 

SC21  N  7970  Enhanced  Functionality  for  Systems  Management  Communications 

SC21  N  7980  Liaison  Statement  to  ITU-TS/SG13  on  Change  Over  Function,  August  1993 

SC21  N  8037  Issues  for  Management  Domain  Management  Function 

SC21  N  8040  Relationship  Management  Function,  Second  Working  Document 

SC21  N  8161  Working  Draft  on  Enhancements  to  Metric  Objects  and  Attributes,  SC21/WQ4,  July  1993 

SC21  N  8162  Working  Draft  for  ICS  Proforma  for  Metric  Objects  and  Attributes,  SC21/WG4,  July  1993 

SC21  N  8163  Working  Draft  for  ICS  Proforma  for  Summarization  Function,  SC21/WG4,  July  1993 

SC21  N  8178  Working  Document  on  Managed  Objects  for  Upper  Layers 

SC21  N  8281  Liaison  Statement  to  SC21/WG4  Concerning  the  OSI  Systems  Management  Implementor's  Guide, 

ITU-TS  SG7,  October  1993 

SC21/WG4  N  1472  US  Response  to  SC 21  N  6679,  Request  for  National  Body  Comments  on  the  Progression  of  an 
Amendment  to  ISO/IEC  10164-11  on  the  Definition  of  Multiple  Input  Metric  Objects 
SC21/WG4  N  1438  UK  Contribution  to  21/63.2,  Testability  of  Managed  Objects 
SC21/WG4  N  1641  Issues  for  Extended  Systems  Management  Architecture  (WG4  SD  1) 

SC21/WG4  N  1831  Second  Working  Draft  on  Expiry  Behavior,  December  1993 
SC21/WG4  N  1832  Command  Sequencer,  Working  Draft,  December  1993 
SC21/WG4  N  1853  Manager  Role  Conformance,  Second  Working  Draft,  December  1993 

ITU-TS  X.700  Management  Framework  for  Open  Systems  Interconnection  (OSI)  for  CCITT  Applications 

(ISO  7498-4),  1992 

ITU-TS  X. 701  Systems  Management  Overview  (ISO  10040),  1992 

ITU-TS  X.702  Application  Context  for  Systems  Management  for  Transaction  Processing  (ISO  11587),  Draft, 

1993 

ITU-TS  X.710  Common  Management  Information  Service  Definition  for  CCITT  Appbcatioae(ISO  9595),  1991 

ITU-TS  X.7 11  Common  Management  Information  Protocol  Specification  for  CCITT  Applications  (ISO  9596-1), 

1991 

ITU-TS  X.712  Common  Management  Information  Protocol:  PICS  Proforma  (ISO  9596-2),  1992 

ITU-TS  X.720  Structure  of  Management  Information:  Management  Information  Model  (ISO  10165-1),  1992 

ITU-TS  X.721  Structure  of  Management  Information:  Definition  of  Management  Infonnatioo  (ISO  10165-2), 

1992 


SC21  N  7109 
SC21  N  7117 
SC21  N  7118 
SC21  N  7119 
SC21  N  7122 
SC21  N  7126 
SC21  N  7129 
SC21  N  7131 
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ITU-TS  X.722 
ITU-TS  X.723 
mi-TSX.724 


ITU-TS  X  725 
ITU  -TS  X.730 
mi  TSX.731 
nr  TSX  732 
mi  TS  X.733 
ITU-TS  X.734 
ITU-TS  X.735 
mi  TS  X  736 
ITU-TS  X.737 
mi  TS  X.738 
ITU-TS  X  739 
mi-TS  X.740 
rru-Tsx  741 
ITU-TS  X.742 
ITU-TS  X.743 
ITU-TS  X.744 
ITU-TS  X.745 
ITU-TS  X.746 
ITU-TS  X.747 
ITU-TS  X.748 
ITU-TS  X.749 
ITU-TS  X.750 

rru-Tsx  751 

ITU-TS  X  752 


Structure  of  Management  Information:  Guidelines  for  the  Definition  of  Managed  Objects 
(ISO  10165-4),  1992 

Structure  of  Management  Information  -  Generic  Management  Information  (ISO  10165-5),  Draft, 
1993 

Structure  of  Management  Information  -  Requirements  and  Guidelines  for  Implementation  of 
Conformance  Statement  Proformas  Associated  with  Management  Information  (ISO  10165-6),  Draft, 
1993 

Structure  of  Management  Information  -  General  Relationship  Model  (ISO  10165-7),  Draft,  1993 

Systems  Management:  Object  Management  Function  (ISO  10164-1),  1992 

Systems  Management:  State  Management  Function  ISO  10164-2),  1992 

Systems  Management:  Attributes  for  Representing  Relationships  (ISO  10164-3),  1992 

Systems  Management:  Alarm  Reporting  Function  (ISO  10164-4),  1992 

Systems  Management:  Event  Report  Management  Function  (ISO  10164-5),  1992 

Systems  Management:  Log  Control  Function  (ISO  10164-6),  1992 

Systems  Management:  Security  Alarm  Report  Function  (ISO  10164-7),  1992 

Systems  Management:  Confidence  and  Diagnosic  Test  Categories  (ISO  10164-14),  Draft,  1993 

Systems  Management-  Summarization  Function  (ISO  10164-13),  Draft,  1993 

Systems  Management:  Metric  Objects  and  Attributes  (ISO  10164-11),  Draft,  1993 

Systems  Management:  Security  Audit  Trail  Function  (ISO  10164-8),  Draft.  1993 

Systems  Management:  Objects  and  Attributes  for  Access  Control  (ISO  10164-9).  Draft,  1993 

Systems  Management:  Usage  Metering  Function  (ISO  10164-10),  Draft,  1993 

Systems  Management,  Test  Management  Function  (ISO  10164-12),  Draft,  1993 

Systems  Management:  Software  Management  Function  (ISO  10164-sw),  Draft,  1993 

Systems  Management:  Time  Management  Function  (ISO  10164-tm),  Draft,  1993 

Systems  Management:  Scheduling  Function  (ISO  10164-15),  Draft,  1993 

Systems  Management:  General  Relationship  Function  (ISO  10164-rm),  Draft,  1993 

Systems  Management:  Response  Time  Monitoring  Function  (ISO  10164-rtm),  Draft,  1993 

Systems  Management:  Management  Domain  Management  Function  (ISO  10164-md).  Draft,  1993 

Systems  Management:  Management  Knowledge  Management  Function  (ISO  10164-16),  Draft, 

1993 

Systems  Management:  Change  Over  Function  (ISO  10164-co),  Draft,  1993 
Systems  Management:  Enhanced  Event  Control  Function  (ISO  10164 -ev).  Draft,  1993 


F.  OSI  REGISTRATION  AUTHORITIES: 


ISO/IEC  9834-1:1993* 


ISO/IEC  9834-2* 
ISO/IEC  9834-3* 


ISO/IEC  9834-4* 
ISO/IEC  9834-5* 
ISO/IEC  9834-6* 

WD  9834-7 
WD  9834-8 
WD  9834-11 

WD  9834-B 
WD  9834-C 
ISO/IEC  TR  9973 
SC21  N  5758 
SC21  N  6903 

ITU-TS  1.414 
ITU-TS  X.660 


Procedures  for  Specific  OSI  Registration  Authorities,  Part  1:  General  Procedures  (X.660) 

PDAM  1  Object  Identifier  Component  Attribute  Type  in  Annex  B  to  Accommodate 
'Short  Form  Names' 

WDAM  2  Incorporate  Definition  of  Root  Arcs  of  Object  Identifier  Tree 
Procedures  for  Specific  OSI  Registration  Authorities,  Part  2:  Registration  Procedures  for  Document 
Types 

Procedures  for  Specific  OSI  Registration  Authorities,  Part  3:  Procedures  for  Specific  Registration  of 
Joint  Object  Identifier  Component  Values  for  Joint  ISO-ITU-TS  Use 

WDAM  1  Amendment  1:  Alignment  with  ISO/IEC  9834-1:1993 
Procedures  for  Specific  OSI  Registration  Authorities,  Part  4:  Register  of  VTE  Profiles 
Procedures  for  Specific  OSI  Registration  Authorities,  Part  5:  Register  of  VT  Control  Objects 
Procedures  for  Specific  OSI  Registration  Authorities,  Part  6:  Registration  Authority  Procedures  for 
Application  Process  Titles  and  Application  Entity  Titles  (X.665) 

Procedures  for  Specific  OSI  Registration  Authorities,  Part  D:  Registration  of  Application  Contexts 
Procedures  for  Specific  OSI  Registration  Authorities,  Part  E:  Registration  of  System  Titles 
Procedures  for  Specific  OSI  Registration  Authorities,  Part  F:  Registration  of  Authentication 
Mechanisms 

Procedures  for  Specific  OSI  Registration  Authorities,  Part  B:  Registration  of  Abstract  Syntaxes 
Procedures  for  Specific  OSI  Registration  Authorities,  Part  C:  Registration  of  Transfer  Syntaxes 
Registration  of  Graphical  Items 
Discussion  Paper  on  Conformance  and  Registration,  BSI 

Request  for  the  Work  on  “Procedures  for  the  Operation  of  Registration  Authorities:  Application 

Processes  and  Application  Entities"  to  Become  Collaborative 

Overview  of  Recommendations  on  Layer  l  for  ISDN  and  B-ISDN  Customer  Accesses 

Procedures  for  the  Operation  of  OSI  Registration  Authorities:  General  Procedures  (ISO  9834-1), 


1992 


ITU-TS  X.662  Procedures  for  the  Operation  of  OSI  Registration  Authorities:  Registration  of  Object  Identifier 

Component  Values  for  Joint  ISO-CCITT  Use  (ISO  9834-3).  Draft.  1993 
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UNCLASSIFIED 


UNCLASSIFIED 


ITU-TSX.665  Flood— »  for  foe  Operetta  of  OSI  Registrstioe  Authorities:  Application  Pro—  aad  Appticeta 

Entitits  (ISO  9934-6).  1992 

G.  OSI  CONFORMANCE  TESTING: 

ISCVIEC  9646-1*  OSI  Conformance  Testing  Methodology  and  Framework.  Part  1:  Oaaaral  Concepts 

AM  1  Protocol  Profile  aad  Multi-Protocol  Tasting 

AM  2  Multi-Party  Testing  Methodology 

Car  1  Technical  Comfead—  1 

DIS  9646-1.2  OSI  Conformance  Testing  Methodology  aad  Fra— work.  Part  1:  General  Concepts.  Second  Edition. 

(incorporating  all  approved  amendments) 

ISCVIEC  9646-2*  OSI  Conformance  Testing  Methodology  aad  Framework,  Part  2:  Abstract  Test  Suite  Specification 
(TTU-TU  X.291) 

Annas  Guidelines  for  PICS  Proformas 

AM  1  Protocol  Profile  aad  Multi -Protocol  Testing 

AM  2  Multi-Party  Tasting  Methodology 

DIS  9646-2.2  OSI  Conformance  Testing  Methodology  and  Framework,  Pad  2:  Abstract  Test  Suite  Specification, 

second  edition 

ISCVIEC  9646-3*  OSI  Conformance  Testing  Methodology  and  Framework,  Part  3.  Executable  Test  Derivation 
(X.292) 

AM  1  TTCN  Extensions 

DAM  2  Further  TTCN  Extensions 

ISCVIEC  9646-4*  OSI  Conformance  Tasting  Methodology  and  Framework,  Pact  4:  Test  RaaHratta  (X.293) 

AM  1  Protocol  Profile  and  Multi-Protocol  Testing 

AM  2  Multi-Party  Testing  Methodology 

DIS  9646-4.2  OSI  Conformance  Testing  Methodology  and  Framework.  Part  4:  Test  Realization,  Edition  2 

ISCVIEC  9646-5*  OSI  Conformance  Testing  Methodology  and  Fra— work.  Part  5:  Requirements  on  Test  Laboratories 

and  Clients  for  tire  Conformance  Assessment  Process  (Test  Execution)  (X.294) 

AM  1  Protocol  Profile  and  Multi-Protocol  Testing 

AM  2  Multi-Party  Testing  Methodology 

Cor  1  Technical  Corrigendum  1 

DIS  9646-5.2  OSI  Confotmanos  Tearing  Methodology  and  Frame work.  Part  5:  Requirements  on  Tost  Laboratories 

and  Clients  for  the  Conformance  Assessment  Process,  second  edition 

ISCVIEC  9646-6  OSI  Conformance  Testing  Methodology  and  Framework.  Pin  6:  Protocol  Profile  Test  Specification 

NS  9646-7  OSI  Conformance  Testing  Methodology  and  Framework.  Part  7:  Requirements  and  Guidelines  on 

Implementation  Conformance  Statement  (ICS)  and  ICS  Proformas 

ISCVIEC  10025-1*  Transport  Conformance  Testing  for  Connection  Orianted  Transport  Protocol  Operating  over  the 
Connection  Oriented  Network  Service  (CONS).  Part  1:  General  Principles 

ISCVIEC  10025-2*  Transport  Conformance  Testing  for  Connection  Oriented  Transport  Protocol  Operating  over  the 
Connection  Oriented  Network  data  Transfer,  Past  1:  Abstract  Service  Definition 

ISCVIEC  10025-3*  Transport  Conformance  Testing  for  Connection  Orienlad  Transport  Protocol  Operating  over  the 
Connection  Oriented  Network  Service  (CONS),  Part  3:  Transport  Test  Management  Protocol 
Specification,  1993 

ISCVIEC  10641  Conformance  Tearing  of  Implementations  of  Graphics  Standards,  1993 

ISCVIEC  10729-1  Conformance  Test  Suite  for  the  Presentation  Protocol.  Part  1:  Test  Suita  Struct—  and  Teat 


rapom  iw  IN  riNNKwOT  r  AMMAN*  SwNBWr  IW 

DIS  10729-2  Conformance  Test  Suita  for  foe  Presentation  Layer.  Part  2:  Teat  Suite  for  ASN.I  Encodings  and  Test 

Purposes  for  Present atine  Protocol  November  1993 

WD  10729-3  Conformance  Teat  Suita  for  foe  Present stion  Layer.  Part  3:  Common  Presentation  Abstract  Test 

Suite,  October  1991 

ISCVIEC  10739-1  Conformance  Test  Suite  for  9041  •  Virtual  Terminal  Basic  Cl—  Protocol.  Part  1:  Teat  Suite 
Structure  and  Tut  Pspotts 

SC21N6160  Catalogue  of  PICS  Proforma  Notations 

SC21N6639  Proposed  Liaison  Statement  to  SC21/WG4  Regarding  General  end  Dependant  Conformance 

SC21  N  6640  Health  Warning  Regarding  General  and  Dependent  Conformance  JTC1-ITU-TS  Interim  Meeting  on 

Conformance 

SC21N6S10  UK  Position  on  General  and  Dependent  Conformance 

SC21  N  6S19  Report  of  the  ISCVIEC-ITU-TS  Joint  OSI  Conform—*  Group  Interim  Meeting  Held  in  Duriuun, 

North  Carolina 

SC21N6M1  Liaison  Statement  to  SC21/WQ1  from  SC1I  on  Conformmc*  to  Raapo—  to  SC18  N  3291 

SC21  N  6*91  Liaison  Statement  to  SClt  and  SC21  on  the  Statue  of  CCTIT  X.4CXVX.500  PICS  Proforma 

Recommendations  and  Fat—  Collaborative  Work 

SC21  N  7016  Presentation  Coonection-Orientad  Abstract  Test  Suite  (ATS),  Specific  Partial  ATS 

SC21  N  7069  Draft  Answer  to  Ql/49.9  on  Long-term  Solution  to  General  and  Dependant  Conformance 
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UNCLASSIFIED 


UNCLASSIFIED 


SC21  N  7073 

SC21  N  7074 
SC21  N  7075 
SC21  N  7076 
SC21  N  7078 
SC21  N  7079 
SC2I  N  7080 
SC21  N  7995 
SC21  N  8010 
SC21  N  8011 
SC21  N  8016 

SC 21  N  8264 

SC2I  N  8355 
SC21/WG1  N  1140 
SC21/WG1  N  1156 
ITU-TS  X290 

ITU-TS  X.291 

ITU-TS  X.292 

ITU-TSX.293 

ITU-TS  X.294 


ITU-TS  X.295 
ITU-TS  X.296 

H.  TAXONOMY 
STAN  AG  4406* 


STAN  AG  4407* 


STAN  AG  4408* 


Proposed  New  Sub-Question  Ql/49.9  on  Long-term  Solution  to  General  and  Dependent 
Conformance 

Liaison  Statement  to  JTCI/SGFS  on  Conformance  Testing 
Liaison  Statement  to  SC 6  on  ICS  Proforma 
Liaison  Statement  to  SCI  8  on  Conformance  Testing 
Draft  Answer  to  Q1/49.8  -  Conformance  and  Registration 
Working  Draft  Answer  to  Q  1/63.2  -  Testability  of  Managed  Objects 
Liaison  Statements  to  EWOS  on  Conformance  Testing 
Working  Draft  on  Formal  Methods  in  Conformance  Testing 
Open  Systems  Assessment  Methodology 

Conformance  Testing  of  OS1  Protocols  over  OS1  Services  Provided  by  Non-OSI  Protocols 
Extensions  to  ISO  9646  on  Testing  of  OS1  Protocols  over  OSI  Services  Provided  by  Non-OSI 
Protocols 

Liaison  Statement  to  SC21/WG1  Conformance  Group  on  Collaborative  Work,  ITU-TS/SG7,  October 
1993 

Liaison  Statement  to  SC21/WG1  and  SC22/WG13  on  Conformance  Testing,  December  1993 
UK  Discussion  Paper  on  Conformance  Testing  for  OSI  Security 
Clarification  on  Use  of  the  PICS 

OSI  Conformance  Testing  Methodology  and  Framework  for  Protocol  Recommendations  for  CCITT 
Applications:  General  Concepts  (DIS  9646-1),  1992 

OSI  Conformance  Testing  Methodology  and  Framework  for  Protocol  Recommendations  for  CCITT 
Applications:  Abstract  Test  Suite  Specifications  (ISO  9646-2),  1992 

OSI  Conformance  Testing  Methodology  and  Framework  for  Protocol  Recommendations  for  CCITT 
Applications:  TTCN  (ISO  9646-3).  1992 

OSI  Conformance  Testing  Methodology  and  Framework  for  Protocol  Recommendations  for  CCITT 
Applications:  Test  Realization  (ISO  9646-4),  1992 

OSI  Conformance  Testing  Methodology  and  Framework  for  Protocol  Recommendations  for  CCITT 
Applications:  Requirements  on  Test  Laboratories  and  Clients  for  Conformance  Assessment 
Process  (ISO  9646-5).  1992 

Conformance  Testing  Methodology  and  Framework  -  Protocol  Profile  Test  Specification  (ISO  9646- 
6).  Draft.  1993 

Conformance  Testing  Methodology  and  Framework  -  Implementation  Conformance  Statements 
(ISO  9646-7),  Draft,  1993 

AND  PROFILES: 

Military  Message  Handling  System.  Draft,  NATO  UNCLASSIFIED  (cf.  ISO  10021, 10611) 

Main  Body.  Draft 

Annex  A — MMHS  Extensions  to  ISO  10021  Series.  Draft 
Annex  B — Security  Aspects  of  MMHS  (under  development) 

Annex  C — Alpha  Profile  Set  (a  della  specification  to  EWOS  profiles):  AMHlx(M)  on 
Common  Facilities  and  AMH9x(M)  on  Military  Messaging,  Draft 
Annex  D — Alpha/ ACP  127  Gateway  (under  development) 

Annex  E — Alpba/MMHS(84)  Gateway  (under  development) 

Annex  F— Alpha/MHS(88)  Gateway  (under  development) 

Annex  G — Beta  Profile  Set  (under  development) 

Annex  H— Beta/ACP  127  Gateway  (under  development) 

Annex  I— Beta/ Alpha  Gateway  (under  development) 

System  Management.  Draft,  NATO  UNCLASSIFIED  (cf.  ISO  10165-1.  10165-2.  10165-4.  10164, 
11183,  12059.  12060) 

Main  Body,  Preliminary  Draft 

Annex  A — Security  of  Management  (under  development) 

Annex  B — Military  Features,  Preliminary  Draft 

Annex  C— The  Development  of  NSPs  for  Systems  Management,  Preliminary  Draft 
Annex  D — NSP  zzzz:  Basic  Systems  Management,  Preliminary  Draft  (STANAG  4407-1) 
Connection-mode  Transport  Service  over  Connection  less-mode  Network  Service 

Part  I:  Subnetwork  Type  Independent  Requirements  for  Group  TA  Preliminary  Draft  (cf. 
ISO  10608-1) 

Part  2:  TASnfM)  Subnetwork  Type  Dependent,  Media  Independent  Requirements  for 
LANs.  Preliminary  Draft  (cf.  ISO  10606-2) 

Part  3:  TA51(M)  Subnetwork  Type  Dependent,  Media  Independent  Requirements  for 
CSMA/CD  LANs,  Pieliminvy  Draft  (cf.  ISO  10606-2) 

Part  4:  TA54(M)  Subnetwork  Type  Dependent,  Media  Independent  Requirements  for  FDDI 
LANs.  Preliminary  Draft  (cf.  ISO  10608-6) 
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UNCLASSIFIED 


UNCLASSIFIED 


STANAG4409* 


STAN  AG  4410* 
STAN  AO  4413* 


ISOIEC  TR  10000-1* 
WDTR  10000-1.3 
ISOIEC  TR  10000-2* 

DTK  10000-2.3* 

WDTR  10000-3 
ISCMEC  ISP  10007-1* 

ISOIEC  ISP  10607-2* 

ISOIEC  ISP  10607-3* 
ISOABC  ISP  10607-4* 

ISOIEC  ISP  10607-3* 

ISOIEC  ISP  10607-6* 
ISOIEC  ISP  10607-x 

ISOIEC  ISP  10607-y 

ISOIEC  ISP  10607-z 

ISOIEC  ISP  10600-1* 

ISOIEC  ISP  10600-2* 

DISP  10600-3 
ISOIEC  10600-4* 
ISOIEC  ISP  10600-3* 

DISP  10600-6* 

MSP  10600-13 
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Connection -mode  Transport  Service  over  Connection-node  Network  Service  (Military) 

Part  1:  Definition  of  Profiles  TC11 11(MVTC1121(M),  Preliminary  Draft  (cf.  ISO  10609- 
6) 

Part  2:  Subnetwork  Type  Independent  Requirements  for  Group  TC,  Preliminary  Draft  (cf. 
ISO  10609-2) 

Part  3:  TA31(M)  Subnetwork  Type  Dependent  Requirements  for  Permanent  Access  to  a 
Packet  Data  Network  Using  Virtual  Call,  Preliminary  Draft  (cf. 
ISO  10609-9) 

Connectionless-mode  Transport  Service  over  Connectionless-mode  Network  Service 

Part  1:  Subnetwork  Type  Independent  Requirements  for  Group  UA,  Preliminary  Draft 
Relaying  the  Connection  less -mode  Network  Service 

Part  1:  Subnetwork  Type  Independent  Requirements  for  Group  RA  (cf.  ISO  10613-1) 
(underdevelopment) 

Part  2:  Subnetwork  Type  Dependent,  Media  Independent  Requirements  for  LANs  (cf.  ISO 
10613-2)  (under  development) 

Part  3:  ISDN  Subnetwork  Dependent,  Media  Dependent  Requirements  for  Circuit  Switched 
B -Channel  Operation  (under  development) 

Part  4:  Profile  RAS 142 12  (under  development) 

International  Standardized  Profiles  (ISPs),  Part  1:  Taxonomy  Framework,  Edition  2 
Framework  of  International  Standardized  Profiles  (ISPs),  Part  1:  Taxonomy  Framework,  Edition  3 
Framework  and  Taxonomy  of  International  Standardized  Profiles,  Part  2:  Taxonomy  of  OSI  Profile, 
Edition  2 

Framework  and  Taxonomy  of  International  Standardized  Profiles,  Part  2:  Taxonomy  of  OSI  Profile, 
Edition  3 

Framework  and  Taxonomy  of  International  Standardized  Profiles,  Part  3:  New  Taxonomy  Pants 
ISPs  AFT  nn  -  File  Transfer,  Access,  and  Management,  Part  1:  Specification  of  ACSE, 
Presentation  and  Session  Protocols  for  the  Use  by  FT AM 

DAM  1  Additional  Specifications  for  COBOL  Document  Types 

ISPs  AFT  nn  -  File  Transfer,  Access,  and  Management,  Part  2:  Definition  of  Document  Types, 
Constraint  Sets  and  Syntaxes 

DAM  1  Additional  Definitions 

DAM  2  Additional  Specifications  for  COBOL  Document  Types 

DAM  3  FTAM  Constraint  Set  and  Document  Type  for  CGM 

ISPs  AFT  nn  -  File  Transfer,  Access,  and  Management,  Part  3:  AFT  II  -  Simple  File  Ihufer 
Service  (Unstructured) 

ISPs  AFT  nn  -  file  Transfer,  Access,  and  Management,  Part  4:  AFT  12  -  Positional  File  Transfer 
Service 

DAM  1  Additional  Specifications  for  COBOL  Document  Types 

ISPs  AFT  nn  -  file  Transfer,  Access,  and  Management,  Part  3:  AFT  22  -  Positional  file  Access 
Service 

DAM  1  Additional  Specifications  for  COBOL  Document  Types 

ISPs  AFT  nn  -  file  Transfer,  Access,  and  Management,  Part  6:  AFT  12  -  file  Management  Service 
ISPs  AFT  nn  -  File  Transfer,  Access  and  Management,  Part  x:  AFT  13  -  Full  File  Transfer 
(Hierarchical),  Draft,  1993 

ISPs  AFT  nn  •  File  Transfer,  Access  and  Management,  Part  y:  AFT  23  •  Full  File  Access 
(Hierarchical).  Draft,  1993 

ISPs  AFT  nn  •  file  Transfer,  Access  and  Management,  Part  z:  AFT  4  -  Filestore  Management 
Profiles,  Draft,  1993 

ISPs  TA  nnnn  -  Connection-mode  Transport  Service  over  Connectionless-mode  Network  Service, 
Part  1:  General  Overview  and  Subnetwork-Independent  Requirements,  1992 
ISPs  TA  nnnn  -  Connection-mode  Transport  Service  over  Connectionless-mode  Network  Service, 
Part  2:  TA51  Profile  Including  Subnetwork-dependent  Requirements  for  CSMA7CD  Local  Area 
Networks,  1992 

ISPs  TA  nnnn  •  Connection-mode  Transport  Service  over  Connectionless-mode  Network  Service, 
Part  3:  TA  32.  LAN.  Token  Bus:  CLNS 

ISP  TA  nnnn  -  Connection-mode  Transport  Service  over  Connectionless-mode  Network  Service. 
Part  4:  TA53  COTS  over  CLNS,  UC3,  Token  Ring  LAN 
ISPs  TA  nnnn  -  Connection-mods  Transport  Service  over  Connectionless -mods  Network  Service, 
Part  3:  TA1111/TA1121  Profiles  Including  Subnetwork-dependent  Requirements  for  X.25  Packet 
Switched  Data  Networks  Using  Switched  Virtual  Circuits,  1992 

ISPs  TA  nnnn  -  Connection-mode  Transport  Servios  over  Connectionless  Network  Service,  Part  6: 
TAM  Profile 

International  Standardized  Profiles  TA  nnnn  -  Connection-mode  Transport  Service  over 
Connectionless  Network  Service,  Pvt  13:  LAN -Dependent  Requirements  for  Token  Ring  MAC  and 
KIY 
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UNCLASSIFIED 


UNCLASSIFIED 


DISP  10608-14* 

ISO/IEC  ISP  10609-1 
ISO/IEC  ISP  10609-2* 
ISO/IEC  ISP  10609-3 
ISO/IEC  ISP  10609-4 
ISO/IEC  ISP  10609-5 
ISO/IEC  ISP  10609-6* 
ISO/TEC  ISP  10609-7 
ISO/IEC  ISP  10609-8 
ISO/IEC  ISP  10609-9* 

pDISP  10609-10 
pDISP  10609-11 
pDISP  10609-12 
pDISP  10609-13 
pDISP  10609-14 
pDISP  10609-20 

pDISP  10609-21 

pDISP  10609  22 

pDISP  10609-23 

pDISP  10609-24 

pDISP  10609-25 


pDISP  10609-26 


pDISP  10609-27 
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ISPs  TA  nnnn  -  Connection-mode  Transport  Service  over  Connectionless  Network  Service, 
Part  14.  MAC.  PHY.  PMD  Sublayer  Dependent  State  Management  Requirement  over  FDDI  LAN 
Subnetwork 

ISPs  TB,  TC,  TD.  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  1 :  Subnetwork-type  Independent  Requirements  for  Group  TB,  1992 
ISPs  TB.  TC,  TD.  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  2:  Subnetwork-type  Independent  Requirements  for  Group  TC,  1992 
ISPs  TB.  TC.  TD.  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  3:  Subnetwork-type  Independent  Requirements  for  Group  TD,  1992 
ISPs  TB,  TC,  TD.  and  TE  -  Connection-mode  Transport  Service  over  Connection -mode  Network 
Service.  Part  4:  Subnetwork-type  Independent  Requirements  for  Group  TE,  1992 
ISPs  TB.  TC.  TD,  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  5:  Definition  of  Profile  TB  111  1/TB  1121,  1992 
ISPs  TB,  TC,  TO,  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  6:  Definition  of  Profile  TC  1 1 1 1/TC  1121,  1992 

ISPs  TB,  TC,  TD.  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  7:  Definition  of  Profile  TD  llll/TD  1121,  1992 

ISPs  TB.  TC,  TD.  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  8:  Definition  of  Profile  TE  1111/TE  1121,  1992 
ISPs  TB.  TC,  TO.  and  TE  -  Connection-mode  Transport  Service  over  Co nneetjon -mode  Network 
Service.  Part  9:  Subnetwork-type  Dependent  Requirements  for  Network  Layer.  DaU  Link  Layer,  and 
Physical  Layer  Concerning  Permanent  Access  to  a  Packet  Switched  Data  Network  Using  Virtual 
Call,  1992 

ISPs  TB.  TC.  TD.  and  TE  -  Connection-mode  Transport  Service  over  Connection-inode  Network 
Service.  Part  10.  1993 

ISPs  TB,  TC.  TD.  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service.  Part  II.  1993 

ISPs  TB.  TC,  TO.  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service.  Part  12:  TC5 1  Profile.  1993 

ISPs  TB.  TC,  TD,  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  13:  TC53  Profile,  1993 

ISPs  TB.  TC.  TD.  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service.  Part  14:  COTS  Classes  0  and  2.  CONS.  LLC2.  Token  Ring  LAN.  1993 
International  Standardized  Profiles  TB.  TC,  TD,  and  TE  -  Connection-mode  Transport  Service  over 
Connection-mode  Network  Service,  Part  20:  TC/TD  nnnn.  Overview  of  the  Generalized  Multipart 
ISP  structure  for  TC  and  TD  Group  Profiles  for  OSI  Usage  of  ISDN,  February  1993  (review  ended  June 
1993) 

International  Standardized  Profiles  TB,  TC.  TD,  and  TE  -  Connection-mode  Transport  Service  over 
Connection-mode  Network  Service,  Part  21:  TC/TD  nnnn.  Subnetwork  Type  Dependent 
Requirements  for  Network  Layer  and  Data  Link  Layer  Concerning  End  Systems  Attached  to  an  ISDN 
Subnetwork  for  B -Channel  X.2S  DTE-to-DTE  Operation.  February  1993  (review  ended  June  1993) 
International  Standardized  Profiles  TB,  TC,  TO.  and  TE  -  Connection-mode  Transport  Service  over 
Connection-mode  Network  Service,  Part  22:  TC/TD  nnnn.  Subnetwork  Type  Dependent 
Requirements  for  Network  Layer  and  Data  Link  Layer  Concerning  End  Systems  Attached  to  an  ISDN 
Subnetwork  for  B -Channel  X.25  DTE-to-DCE  Operation,  February  1993  (review  ended  June  1993) 
International  Standardized  Profiles  TB,  TC.  TO,  and  TE  -  Connection-mode  Transport  Service  over 
Connection-mode  Network  Service,  Part  23:  TC/TD  nnnn.  Subnetwork  Type  Dependent 
Requirements  for  Network  Layer  and  Data  Link  Layer  for  Data  Transfer  Concerning  Packet-Switched 
Mode  ISDN  Virtual  Calls:  B-Chartnel  Access  Case,  February  1993  (review  ended  June  1993) 
International  Standardized  Profiles  TB,  TC.  TO.  and  TE  -  Connection-mode  Transport  Service  over 
Connection-mode  Network  Service,  Part  24:  TC/TD  nnnn.  Subnetwork  Type  Dependent 
Requirements  for  Network  Layer  Using  Q.931  -  Circuit-Switched  Case.  February  1993  (review  ended 
June  1993) 

International  Standardized  Profiles  TB.  TC.  TD,  and  TE  -  Connection-mode  Transport  Service  over 
Connection -mode  Network  Service,  Part  25:  TC/TD  nnnn.  Subnetwork  Type  Dependent 
Requirements  for  Network  Layer  for  Call  Control  Procedures  Concerning  the  Outgoing  Call  of  a 
Packet-Switched  Mode  ISDN  in  Case  B  Using  Virtual  Calls,  February  1993  (review  ended  June 
1993) 

International  Standardized  Profiles  TB.  TC,  TO,  and  TE  •  Connection-mode  Transport  Service  over 
Connection-mode  Network  Service,  Part  26:  TC/TD  nnnn.  Subnetwork  Type  Dependent 
Requirements  for  Network  Layer  for  Call  Control  Procedures  Concerning  the  Outgoing  Call  of  a 
Packet-Switched  Mode  ISDN  in  Case  B  Using  Virtual  Calls,  February  1993  (review  ended  June 

1993) 

International  Standardized  Profiles  TB.  TC.  TD,  and  TE  •  Connection-mode  Transport  Service  over 
Connection-mode  Network  Service.  Part  27:  TC/TD  nnnn.  Subnetwork  Type  Dependent 
Requirements  for  Network  Layer  for  Call  Control  Procedures  Concerning  the  Incoming  Call  of  a 
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Pack*! -Switched  Mode  BDN  in  Ceae  B  Using  Virtual  Call*.  February  1993  (review  ended  lone 
1993) 

International  Standardized  Profiler  TB,  TC,  TD,  and  IE  -  Coonectiottmode  Tranrport  Service  over 
Connection-mode  Network  Service,  Part  28:  TC/TD  onnn,  Subnetwork  Type  Dependent 
Requirement!  for  Dcta  Link  Layer  for  End  Syrtemr  Attached  to  an  ISDN  Subnetwork,  February  1993 
(review  ended  June  1993) 

International  Standardized  Profile*  TB.  TC.  TD.  and  TE  -  Connection -mode  Tranrport  Service  over 
Connection-inode  Network  Service.  Part  29:  TC  1131,  ISDN  B -Channel  Virtual  Call.  Permanent 
Accer*  to  a  PSDN  -  Transport  Protocol  Classes  0  and  2,  February  1993  (review  ended  June  1993) 
International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connection-mode  Transport  Service  over 
Connection-mode  Network  Service,  Part  30:  TC  1131,  BDN  B -Channel  Virtual  Call,  Switched 
Access  to  a  PSDN  -  Transport  Protocol  Classes  0  and  2.  February  1993  (review  ended  June  1993) 

ISPs  TB,  TC,  TD,  and  TE  -  Connection-mode  Transport  Sendee  over  Connection -mode  Network 
Service,  Part  31:  TC  1231,  ISDN  B -Channel  Virtual  Call,  Switched  Access  to  a  PSDN,  1993 
ISPs  TB,  TC,  TD,  snd  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  32:  TC  4111,  BDN  B -Channel  X.25  DIE  to  DTE,  Semi-permanent  Service,  1993 
ISPs  TB,  TC,  TD,  and  TE  •  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  33:  TC  4112,  BDN  B -Channel  X.25  DTE.  Circuit-mode  Service.  1993 
ISPr  TB,  TC,  TD,  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  34:  TC  43111,  BDN  D-Channel  Access  Virtual  Call,  Packet-mode  Service,  Without 
Q.931,  1993 

BPs  TB,  TC,  TD,  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  33:  TC  43112,  ISDN  D-Channel  Access  Virtual  Call,  Packet-mode  Service,  with 
Q.931,  1993 

ISPs  TB,  TC,  TD,  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  36:  TC  43211,  BDN  B -Channel  Permanent  Acoees  Virtual  Call,  Packet-mode  Service, 
Without  Q.931,  1993 

ISPs  TB,  TC,  TD,  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  37:  TC  43212,  BDN  B -Channel  Permanent  Access  Virtual  Call,  Packet-mode  Service, 
with  Q.931,  1993 

BPs  TB,  TC,  TD.  and  TE  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service,  Part  38:  TC  4331,  BDN  B -Channel  Demand  Access  Virtual  Call,  Packet-mode  Service, 
1993 

International  Standardized  Profiles  TB,  TC,  TD.  and  TE  -  Connection -mode  Transport  Service  over 
Connection-mode  Network  Service,  Past  40:  TD  1131,  ISDN  B -Channel  Virtual  Call,  Permanent 
Accem  to  a  PSDN  •  Transport  Protocol  dam  0,  February  1993  (review  aadad  June  1993) 
International  Standardized  Profiles  IB,  TC,  TD,  and  TE  -  Connection-mode  Transport  Service  over 
Connection -mode  Network  Service.  Part  41:  TD  1231,  BDN  B -Channel  Virtual  Call.  Switched 
Accem  to  a  PSDN  -  Transport  Protocol  Class  0.  February  1993  (review  ended  June  1993) 
International  Standardized  Profiler  TB,  TC,  TD,  and  TE  -  Connection-mode  Trauport  Service  over 
Connection-mode  Network  Service,  Part  42:  TD4111,  BDN  B -Channel,  X.25  DIE-to-DTE,  Semi¬ 
permanent  Service  -  Transport  Protocol  Clam  0,  February  1993  (review  ended  June  1993) 
International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connectionmode  Tranrport  Service  over 
Connection-mode  Network  Service,  Part  43:  TD  4211,  ISDN  B -Channel,  X.25  DTE-to-DTE, 
Circuit-mode  Service  •  Transport  Protocol  Class  0,  February  1993  (review  ended  June  1993) 
International  Standardized  Profiler  TB,  TC,  TD,  and  TE  -  Connection-mode  Transport  Service  over 
Connection-mode  Network  Service,  Part  44:  TD  43111,  ISDN  D-Channel  Accem  Virtual  Call. 
Packet-mode  Service,  Without  Q.931  -  Transport  Protocol  Classes  0.  February  1993  (review  ended 
June  1993) 

International  Standardized  Profile*  TB,  TC,  TD,  and  TE  •  Connection-mode  Transport  Service  over 
Connection-mode  Network  Service,  Part  45:  TD  43112,  BDN  D-Channel  Accem  Virtual  Call, 
Packetmode  Service,  With  Q.931  -  Transport  Protocol  Classes  0,  February  1993  (review  coded  Jane 
1993) 

International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connectionmode  Transport  Service  over 
Connectionmode  Network  Service,  Part  46:  TD  43211,  ISDN  B-Chanoel  Permanent  Access  Virtual 
Call,  Packet-mode  Service,  Without  Q.931  -  Transport  Protocol  Classes  0,  February  1993  (review 
ended  June  1993) 

International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Conoectioomoda  Transport  Service  over 
Connection-mode  Network  Service,  Part  47:  TD  43212,  BDN  B-Cbsnael,  Permanent  Accem 
Virtual  Call,  Packetmode  Service,  With  Q.931  •  Transport  Protocol  Classes  0,  February  1993 
(review  ended  June  1993) 

International  Standardized  Profile!  TB,  TC,  TD,  and  TE  •  Connection  mode  Transport  Service  over 
Connection-mode  Network  Service,  Part  48:  1D  43212,  BDN  B -Channel,  Demand  Accem  Virtual 
Call,  Packetmode  Service  •  Transport  Protocol  Classes  0,  February  1993  (review  ended  June  1993) 
ISPs  POD  no.  Part  1:  POD  11  Profile,  Simple  Document  Structure  .  Character  Content  Only,  April 
1992 

ISP*  AMHln  •  Message  Handling  Systems  -  Common  Massaging,  Part  1:  Service  Support,  1993 

D-19  Architectural  and  General  Standards 


UNCLASSIFIED 


UNCLASSIFIED 


MSP  10611-2* 
NSP  10611-3* 
MSP  10611-4* 
MSP  10611-3* 
pDISP  10612-1 
pMSP  10612-2 
pMSP  10612-3 


MSP  10612-4* 
pMSP  10612-3 


pMSP  10612-6 

pMSP  10612-7 

pMSP  10612-6 

pMSP  10612-9 

pMSP  10613-1* 
pMSP  10613-2* 

MSP  10613-3* 

MSP  10613-4 


pMSP  10613-3* 

pMSP  10613-6 

pMSP  10613-7* 

pMSP  10613-6* 

pMSP  10613-9* 

pMSP  10614-1 

pMSP  10614-2 

pMSP  10614-3 

pMSP  106144 
MSP  10614-3* 

MSP  106144* 

MSP  10613-1* 

MSP  10613-2* 

MSP  10613-3* 

MSP  106134* 
pMSP  10613-3 
pMSP  106134 
pMSP  10613-7 
pMSP  10616 
ISOflBC  BP  11181-1 


ISP*  AMHln  •  Message  Handling  Systems  -  Common  Messaging,  Pvt  2:  Specification  of  ROSE, 
RTSS,  ACSE,  Presentation,  and  Session  for  Use  by  MHS,  1993 

ISPs  AMHln  •  Message  Handling  Systems  -  Common  Messaging.  Part  3:  AMHU:  Message 
Transfer  (PI),  1993 

ISPs  AMHln  •  Message  Handling  System*  •  Common  Messaging,  Pvt  4:  AMHU:  MTS  Access 
(PI),  1993 

ISPs  AMHln  •  Message  Handling  Systems  -  Common  Messaging,  Parat  3:  AMHU:  MS  Access 
(P7%  1993 

ISPs  RD  nn.nn,  Part  1:  RD  5p.5q  Profile,  Relaying  MAC  Using  Transparent  Bridging  -  General 
Overview  and  Subnetwork  Independent  Requirement,  1993 

ISPs  RD  mum,  Part  2:  RD  5pSq  Profile,  Relaying  MAC  Using  Transparent  Bridging  -  CSMA/CD 
LAN  Subnetwork  Dependent  Media  Dependent,  1993 

International  Standardized  Profiles  RD  nn.nn  -  Relaying  the  MAC  Service  Using  Transport 
Bridging.  Part  3:  RD  5p5q  Profile,  Token  Ring  LAN  Subnetwork-Dependent  Media-Dependent 
Requirements,  May  1993  (balloting  ended  September  1993) 

ISPs  RD  mum.  Part  4:  RD  51.51  Profile,  Relaying  MAC,  1993 

International  Standardized  Profile*  RD  nn.nn  -  Relaying  die  MAC  Service  Using  Transport 
Bridging,  Part  3:  RD  51.54  Profile,  CSMA/CD  -  FDDL  May  1993  (balloting  ended  September 
1993) 

International  Standardized  Profiles  RD  nn.nn  -  Relaying  the  MAC  Service  Using  Transport 
BAighg,  pvt  6:  RD  51.53  Profile,  FDD!  -  FDD!,  May  1993  (balloting  ended  September  1993) 

ISPs  RD  mum.  Part  7:  RD  51.53  Profile,  MAC  Service  Relay  Using  Transparent  Bridging, 
CSMA/CD  -  Token  Ring,  1993 

ISPs  RD  mum.  Part  S:  RD  5333  Profile,  MAC  Service  Relay  Using  Transparent  Bridging,  Token 
Ring  -  Token  Ring.  1993 

ISPs  RD  mum.  Pert  9:  RD  5354  Profile,  MAC  Service  Relay  Using  Transparent  Bridging,  Token 
Ring  -  FDDL  1993 

ISPS  RA  mum  -  Relaying  the  Connectionless-mode  Network  Service,  Part  1:  Relay  Function,  1993 
ISPs  RA  mum  -  Relaying  the  Connectionless-mode  Network  Service.  Part  2:  LAN  Subnetwork, 
1993 

ISPs  RA  mum  -  Relaying  the  Connectionless-mode  Network  Service,  Part  3:  CSMA/CD  LAN 
Subnetwork.  1993 

International  Standardized  Profiles  RA  mum  -  Relaying  the  Connectionless-mode  Network  Service, 
Part  4:  FDDI  LAN  Subnetwork-Dependent  Media-Dependent  Requirements,  1993  (review  ended 
April  1993) 

ISPs  RA  mum  -Relaying  the  Connectionlees-mode  Network  Service,  Part  3:  RA31.51  nofile. 
Relaying  CLNS  -  CSMA/CD,  1993 

Intern  Vionsl  Standardized  Profiles  RA  mum  •  Relaying  the  Connectionless-mode  Network  Service, 
Pvt  6:  RA  3134,  CSMA/CD  LAN  and  HNX  LAN,  1993  (review  ended  April  1993) 

ISPs  RA  Brum  -  Relaying  the  Connectkmlen-mode  Network  Service.  Part  7:  PSDN  Subnetwork 
Media  Dependent  VC  Permanent  Access,  1993 

ISPs  RA  mum  -  Relaying  the  Connectionless -mode  Network  Service,  Part  8:  RA51.1111  Profile, 
1993 

ISPs  RA  nman  •  Relaying  the  Connectionless-mode  Network  Service,  Part  9:  RA51.U21  Profile. 
1993 

ISPs  RC  nn.nn  •  Relaying  X.23  PLP,  Part  1:  General  Overview  and  Subnetwork  Independent 
Requirement.  1993 

ISPs  RC  mum  •  Relaying  X.23  PLP,  Pvt  2:  LAN  Subnetwork  Dependent  Media  Independent 
Raqntoamant,  1993 

ISPs  RC  mum  -  Relaying  X.23  PLP,  Part  3:  CSMA/CD  LAN  Subnetwork  Dependent  Media 
Dependent,  1993 

ISPs  RC  mum  -  Relaying  X.25  PLP,  Pvt  4:  PSDN  Subnetwork  Type  Dependent  Requirement,  1993 
ISPs  RC  mum  •  RCSl.llll,  Relaying  X.25,  Part  3,  1993 
ISPs  RC  mum  -  RC51.1121.  Relaying  X.25,  Pvt  6,  1993 

ISPB  ADI  mi  -  OSI  Directory,  Part'l:  ADI  11,  DUA  support  of  Directory  access,  January  1993 

ISPs  ADI  an  -  OSI  Directory,  Part  2:  ADI  12,  DSA  support  of  Directory  access,  January  1993 

ISPs  ADI  an  -  OSI  Directory,  Part  3:  ADI  21,  DSA  respooder  role.  July  1993 

ISPs  ADI  mi  -  OSI  Directory,  Part  4:  AIM  22,  DSA  initiator  role,  July  1993 

ISPi  ADI  tm  -  OSI  Directory,  Part  5:  AIM  31,  DUA  Support  of  Distributed  Operations,  1993 

ISPs  ADI  mi  -  OSI  Directory,  Part  6:  ADI  32,  DSA  Support  of  Distributed  Operations,  1993 

ISPs  ADI  on  -  OSI  Directory,  Pvt  7:  AIM  41,  Strong  Authentication.  1993 

ISP  FIM  11  -  Directory  Data  Definitions  -  Common  Directory  Use,  September  1993 

ISP  FOD26  •  Enhanced  Document  Structure  •  Character,  Raster  Graphic*  and  Geometric  Graphic* 

Content  Architecture,  April  1992 
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ISQfflEC  ISP  11182-1  ISP  FOD36  •  Extended  Document  Structure  ■  Character,  Raatar  Graphica  and  Geometric  Graphic* 
Content  Architecture,  April  1992 

ISOftEC  ISP  IU83-1*  ISPs  AOM  Id  -  OSI  Management  -  Management  Communicationi  Protocols,  Part  1: 

Specification  of  ACSE,  Presentation  and  Session  Protocols  for  the  Use  by  ROSE  and  CMISE, 
Revised  Edition,  December  1992 

ISOflEC  ISP  lllS3-2e  ISPs  AOM  In  -  OSI  Management  -  Management  Communications  Protocols,  Part  2: 

CMISE/ROSE  for  AOM  12,  Rnhsnced  Management  Commoaicatioos,  1999 
pOISP  11183-x  ISPs  AOM  In  -  OSI  Management  -  Management  Communications  Protocols,  Past  x:  Development 

of  PIS  for  CMIP  (AOM  11,  AOM  12).  1993 

pDISP  11184-1  ISPs  FVT  Inn  -  Virtual  Terminal  Buie  Clau  •  Register  of  VTE  Profiles,  Part  1:  PVT  121  -  Sends 
Forms  VTE  Profile,  1993 

pDISP  11184-2  ISPs  FVT  Inn  -  Virtual  Terminal  Buie  Class  -  Register  of  VTE  Profiles,  Part  2:  FVT  122- S-mode 

Paged  VTE  Profile,  1993 

pDISP  1US4-3  ISPs  FVT  Inn  •  Virtual  Terminal  Buie  Clau  •  Register  of  VTE  Profiles,  Part  3:  FVT  111  -  A-mode 
Telnet  Profile 

pDISP  11184-4  ISPs  FVT  Inn  •  Virtual  Terminal  Basic  Clau  •  Register  of  VTE  Profilet,  Part  4:  FVT  112  •  A-mode 
Scroll  VTE  Profile 

pDISP  11184-5  ISPs  FVT  Inn  -  Virtual  Terminal  Basic  Clad  -  Register  of  VTE  Profiles,  Part  5:  FVT  113  -  A-mode 
CdTT  X.3  PAD  Interworking 

pDISP  11184-4  ISPs  FVT  Inn  -  Virtual  Terminal  Basic  Clad  -  Register  of  VTE  Profiles,  Part  6:  FVT  114  -  A-mode 
Transperent  VTE  Profile 

pDISP  11184-7  ISPs  FVT  Inn  -  Virtual  Terminal  Buie  Clau  -  Register  of  VTE  Profiles,  Part  7:  FVT  115  -  A-mode 
Generalized  Telnet  VTE  Profile,  1993 

pDISP  11185-1  ISPs  FVT  2nn  -  Virtual  Terminal  Basic  Clau  -  Register  of  VT  Control  Objects.  Part  1:  FVT  211, 
FVT  212,  Sequenced  and  Unsequenced  Application  Control  Objects,  1993 
pDISP  11185-2  ISPs  FVT  2an  -  Virtual  Terminal  Buie  Clau  -  Register  of  VT  Control  Objects.  Part  2:  FVT  213, 
FVT  214,  Sequenced  and  Unsaquenced  Terminal  Control  Objects,  1993 
pDISP  11185-3  ISPk  FVT  2nn  -  Virtual  Terminal  Basic  Clau  -  Register  of  VT  Control  Objects,  Part  3:  FVT  215, 
FVT  216,  Application  RIO  Record  Locating  Control  Object  and  Terminal  RIO  Record  Notification 
Control  Object,  1993 

pDISP  11185-4  ISPs  FVT  2tm  -  Virtual  Terminal  Baric  Clau  -  Register  of  VT  Control  Objects.  Part  4:  FVT  217, 
Horizontal  Tabulation  Control  Object,  1993 

pDISP  11185-5  ISPs  FVT  2nn  -  Virtual  Terminal  Baric  Clau  -  Register  of  VT  Control  Objects.  Part  5:  FVT  218, 
Logical  Image  Control  Object,  1993 

pDISP  11185-6  ISP*  FVT  2nn  -  Virtual  Terminal  Basic  Clau  -  Register  of  VT  Control  Objects.  Put  6:  FVT  219, 

Status  Message  Control  Object,  1993 

pOISP  11185-7  ISPS  FVT  2nn  •  Virtual  Terminal  Basic  Clau  -  Register  of  VT  Control  Objects.  Part  7:  FVT  220, 
Entry-control  Control  Object,  1993 

pDISP  11185-8  ISPs  FVT  2aa  -  Virtual  Terminal  Basic  Clau  -  Register  of  VT  Control  Objects,  Part  8:  FVT  221, 
Forms  Field  Entry  Instruction  Control  Object  (FE1CO)  No.  1, 1993 
pDISP  U185-9  ISPs  FVT  2nn  -  Virtual  Terminal  Baric  Oau  •  Register  of  VT  Control  Objects,  Part  9:  FVT  22Z 
Paged  Field  Entry  Instruction  Control  Object  (PEICO)  No.  1.  1993 
pDISP  11185-10  ISP*  FVT  2na  -  Virtual  Terminal  Basic  Clau  -  Register  of  VT  Control  Objects.  Part  10:  FVT  231, 
Forms  Held  Entry  Pilot  Control  Object  (FEPCO)  No.  1, 1993 

pDISP  11185-11  ISPs  FVT  2nn  •  Virtual  Terminal  Basic  Clau  -  Register  of  VT  Cootrol  Objects,  Part  11:  FVT  232, 
Paged  Held  Entry  Pilot  Control  Object  (PEPCO)  No.  1, 1993 

pDISP  11185-12  ISPs  FVT  2nn  -  Virtual  Terminal  Baric  Clau  •  Register  of  VT  Control  Objects,  Part  12:  FVT  251, 
Terminal  Conditions  Control  Object  No.  1 

pDISP  11185-13  ISPs  FVT  2an  -  Virtual  Terminal  Basic  dus  -  Register  of  VT  Control  Objects,  Part  13:  FVT  2111, 
Writing  Time  Control  Object  (pDISP  expected  1995) 

pDISP  11185-14  ISPs  FVT  2an  -  Virtual  Terminal  Basic  Class  -  Register  of  VT  Control  Objects.  Put  14:  FVT  2112. 

Printer  Control  Object,  1993 

pDISP  11185-15  ISPs  FVT  2on  -  Virtual  Tenninal  Bask  Clan  -  Register  of  VT  Control  Objects,  Put  15:  PVT  2113, 
Held  Definition  Control  Object,  1993 

pDISP  11185-16  ISPs  FVT  2im  -  Virtual  Terminal  Baric  Clau  •  Register  of  VT  Cootrol  Objects,  Part  16:  FVT  2114, 
Terminal  Signal  Titles  Control  Object,  1993 

pDISP  11185-17  ISPs  FVT  2an  -  Virtual  Tenninal  Basic  Clau  •  Register  of  VT  Control  Objects,  Part  17:  FVT  2115, 
Form  Help  Text  Cootrol  Object,  1993 

pDISP  11186-1  ISPs  FVT  3 on  •  Virtual  Terminal  Basic  Clau  •  Register  of  Assignment  Type  Definitions,  Part  1: 
FVT  321,  Pont  Assignment  Type  No.  1 

MSP  11187-1*  ISPs  AVT  In,  AVT  2n  -  Virtual  Tenninal  Baric  Qua  ■  Application  Profiles,  Put  l:  AVT  22,  S-mode 
Forms  Application  Profile,  1993 

D(SP  11187-2*  ISPs  AVT  In,  AVT  2n  -  Virtual  Tenninal  Baric  Clau  •  Application  Profiles,  Put  2:  AVT  23,  Smods 
Paged  Application  Profile,  1993 

pDISP  11187-3  ISPs  AVT  In,  AVT  2a  -  Virtnal  Terminal  Basic  Clan  -  Application  Profiles,  Put  3:  S-mode  ISPICS 
Requirements  List  No.  1 
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UNCLASSIFIED 


UNCLASSIFIED 


pOBP  11187-4 

pDISP  11187-6 

pDISP  11187-7 

pDISP  11187-8 

pDISP  11187-9 

pDISP  11187-10 

pDISP  11188-1 
pDISP  11188-2 
pDISP  11188-3 
DISP  11189 
DISP  11190 
EHSP  12059-0 

DISP  1 2059-1* 

DISP  12059-2* 

DISP  12059-3* 

DISP  12059-4* 

DISP  12059-5* 

DISP  12059-6* 

DISP  12060-1* 

DISP  12060-2 

DISP  12060-3 

DISP  12060-4* 

DISP  12060-5* 

DISP  12060-w 

MSP  12060-x 

MSP  12060-y 
DISP  12060-x 

MSP  12061-1 
MSP  12061-2 
MSP  12061-3 
DISP  12061-4 

MSP  12061-5 

DISP  12061-6 

MSP  12061-7 

MSP  12061-8 

pDISP  12061-9 

pDISP  12061-10 
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ISPi  AVT  In,  AVT  2n  -  Virtual  Terminal  Basic  Class  -  Application  Profiles,  Part  4,  S-mode  ISPICS 
Requirements  (IPRL)  List  No.  1,  Supporting  Layers  List  No.  1 

ISPs  AVT  In,  AVT  2n  •  Virtual  Terminal  Basic  Class  •  Application  Profiles,  Part  6:  AVT  13, 
A-mode  Scroll  Application  Profile 

ISPs  AVT  In,  AVT  2n  -  Virtual  Terminal  Basic  Class  -  Application  Profiles,  Part  7:  AVT  14, 
A-mode  CCTTTX.3  PAD  Application  Profile 

ISPs  AVT  In,  AVT  2n  -  Virtual  Terminal  Basic  Class  -  Application  Profiles,  Part  8:  AVT  15, 
A-mode  Transparent  Application  Profile 

ISPs  AVT  In,  AVT  2n  •  Virtual  Terminal  Basic  Class  -  Application  Profiles,  Part  9:  AVT  16, 
A-mode  Generalized  Telnet  Application  Profile,  1993 

ISPs  AVT  In,  AVT  2n  -  Virtual  Terminal  Bask  Class  -  Application  Profiles,  Part  10:  AVT  17, 
A-mode  ISPICS  Requirements  list  No.  1 

ISPs  -  Common  Upper  Layer  Requirements,  Part  1:  Bask  Connection  Oriented  Requirements,  1993 

ISPs  •  Common  Upper  Layer  Requirements,  Part  2:  ROSE  Based  Requirements,  1993 

ISPs  -  Common  Upper  Layer  Requirements,  Part  3:  Minimal  OSI  Upper  Layer  Facilities,  July  1993 

ISP  FM2  -  MHS  Use  of  Directory,  1993 

ISP  FDD  -  FTAM  Use  of  Directory,  1993 

ISPs  -  Management  Functions  -  Common  Information  for  Management  Functions,  Part  0:  Common 
Definitions  for  Management  Function  Profiles,  1992 

ISPs  •  Management  Functions  -  Common  Information  for  Management  Functions,  Part  1:  Object 
Management,  1992 

ISPs  •  Management  Functions  -  Common  Information  for  Management  Functions,  Part  2:  State 
Management,  1992) 

ISPs  •  Management  Functions  •  Common  Information  for  Management  Functions,  Part  3: 
Attri  balsa  for  Representing  Relating  ships,  1992 

ISPs  •  Management  Functions  •  Common  Information  for  Management  Functions,  Part  4:  Alarm 
Reporting,  1992 

ISPs  -  Management  Functions  •  Common  Information  for  Management  Functions,  Part  5:  Event 
Report  Management,  1992 

ISPs  •  Management  Functions  -  Common  Information  for  Management  Functions,  Part  6:  Log 
Control,  1992 

ISPs  AOMum  -  OSI  Management  -  Management  Functions,  Part  1:  AMI  211,  General  Management 
Capability.  1992 

ISPs  AOMnna- OSI  Management -Management  Functions,  Part  2:  AOM  212,  Alarm  Reporting  and 
State  Management  Capabilities,  1992 

ISPs  AOMnnn  -  OSI  Management  -  Management  Functions,  Part  3:  AOM  213,  Alarm  Reporting 
Capabilities,  1992 

ISPs  AOMnnn  -  OSI  Management  -  Management  Functions,  Part  4:  AOM  221,  General  Event 
Report  Management,  1992 

ISPs  AOMnnn  -  OSI  Management  -  Management  Functions.  Part  5:  AOM  231,  General  Log 
Control,  1992 

ISPs  AOMnnn  -  OSI  Management  -  Management  Functions,  Part  w:  AMI  242,  Security  Protocols 
(ISP  expected  November  1993) 

ISPs  AOMnnn  -  OSI  Management  -  Management  Functions,  Part  z:  AOM  251,  General  Performance 
Profile  (ISP  expected  September  1994) 

ISPs  AOMnnn  -  OSI  Management  -  Management  Functions.  Part  y:  AOM  252x,  Metric  Objects 
ISPs  AOMnnn  -  OSI  Management  •  Management  Functions,  Put  z  AOM  253x,  Summarization 
Objects 

ISPs  ATP  na  •  OSI  Distributed  Transaction  Processing.  Part  1:  Introduction,  1993 
ISPs  ATP  nn  -  OSI  Distributed  Transaction  Processing,  Part  2:  Support  of  the  OSI  TP  APDUs,  1993 
ISPS  ATP  nn  •  OSI  Distributed  Transaction  Processing,  Part  3:  Support  of  the  OCR  Protocols.  1993 
ISPs  ATP  nn  •  OSI  Distributed  Transaction  Processing,  Part  4:  Support  of  ACSE,  Presentation  and 
Session  Protocols,  1993 


ISPs  AT?  nn  •  OSI  Distributed  Transaction  Processing,  Part  5:  ATP  11,  Application  Supported 
Transactions  with  Polarized  Control,  1993 

ISPs  AT?  nn  -  OSI  Distributed  Transaction  Processing.  Part  6:  ATP  12,  Application  Supported 
Transactions  with  Shared  Control,  1993 

ISPs  ATP  an  •  OSI  Distributed  Transaction  Processing,  Part  7:  ATP  21,  Provider  Supported 
Transactions  in  Unchained  Mode  with  Polarized  Control,  1993 

ISPs  ATP  nn  -  OSI  Distributed  Transaction  Processing,  Part  8:  ATP  22,  Provider  Supported 
Transactions  in  Unchained  Mode  with  Shared  Control,  1993 


ISPs  ATP  nn  •  OSI  Distributed  Transaction  Processing,  Part  9: 
Transactions  in  Chained  Mode  with  Polarized  Control,  1993 
ISPs  AT?  an  -  OSI  Distributed  Transaction  Processing,  Part  10: 
Transaction*  fat  Chained  Mode  with  Shared  Control,  1993 


ATP  31,  Provider  Supported 
ATP  32,  Provider  Supported 
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UNCLASSIFIED 


UNCLASSIFIED 


pDISP  12061-11 

pDISP  12061-x 
pDISP  12061-y 
pDISP  12062-1 

pDISP  12062-2 

pDISP  12062-3 

pDISP  12062-4 

pDISP  12062-S 

pDISP  12063 
pDISP  12064-1 

pDISP  12065-1 

pDISP  12066-1 

pDISP  12066-2 

SC21  N  6776 

SC21  N  7197 
SC21  N  7360 

SC21  N  8118 
SOPS  N  1056 


ISPs  ATP  on  -  OSI  Distributed  Transaction  Processing.  Part  11:  TP  Transaction  Recovery 
Application  Context,  1993 

ISPs  ATP  nn  -  OSI  Distributed  Transaction  Processing,  Part  x:  Systems  Profiling  for  TP,  1993 
ISPs  ATP  nn  -  OSI  Distributed  Transaction  Processing,  Part  y:  Development  of  PTS  for  TP,  1993 
International  Standardized  Profiles  AMH  nn  •  Message  Handling  Systems  -  Interpersonal 
Messaging,  Part  1:  IPM  MHS  Service  Support,  August  1993  (review  ended  December  1993) 
International  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems  -  Interpersonal 
Messaging,  Part  2:  AMH  21,  IPM  Content,  August  1993  (review  ended  December  1993) 
International  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems  -  Interpersonal 
Messaging,  Part  3:  AMH  22,  IPM  Requirements  for  Message  Transfer  (PI),  August  1993  (review 
ended  December  1993) 

International  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems  •  Interpersonal 
Messaging,  Part  4:  AMH  23,  IPM  Requirements  for  MTS  Access  (P3).  August  1993  (review  ended 
December  1993) 

International  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems  -  Interpersonal 
Messaging,  Part  5:  IPM  Requirements  for  Enhanced  MS  Access  (P7),  August  1993  (review  ended 
December  1993) 

International  Standardized  Profiles  AMH  3  -  Message  Handling  Systems,  1993 
International  Standardized  Profiles  POD  nnn  •  ODA  -  Open  Document  Format:  Image  Applications  • 
Simple  Document  Structure  -  Raster  Graphics  Content  Architecture,  Part  1:  POD  112,  Document 
Applications  Profile,  August  1993  (balloting  ended  December  1993) 

International  Standardized  Profiles  ALD  In  -  Library  and  Documentation  -  Search  and  Retrieve, 
Part  1:  Specification  of  ACSE,  Presentation,  and  Session  Protocols  for  Uae  by  Library  and 
Documentation,  August  1993 

International  Standardized  Profiles  ALD  2n  -  Library  and  Documentation  -  In tc.  library  Loan,  Part  1: 
Generic,  August  1993 

International  Standardized  Profiles  ALD  2n  -  Library  and  Documentation  -  Interlibrary  Loan,  Part  2: 
Using  Connection-Oriented  ACSE,  August  1993 

Framework  A  Taxonomy  of  International  Standardized  Profiles  -  Directory  of  ISPs  A  Profiles 
Contained  Therein 

Response  to  the  Request  from  SGFS  for  Comments  on  Issues  Regarding  Registration  and  ISPs 
Development  of  the  SGFS  Procedures  to  Cover  Other  TCs  and  the  Open  System  Environment 
(SGFS  N  590) 

Report  from  the  SC21  ISP  Meeting.  23  lime  1993,  Yokohama,  June  1993 

EWOS  Major  Comment!  on  the  Third  Working  Draft  of  TR  10000  Part  3  (ISO/IEC  JTC1/SGFS 
N  1024)  and  Proposals  for  Change,  EWOS,  November  1993 


I.  MODELLING  FACILITIES: 


JTC1  N  2621 

JTC1  N  2775 

JTC1N2835 

SC21  N  8056 
SC21  N  8057 

SC21  N  8058 

SC21  N8QS9 

SC21  N  8061 

SC21  N  8062 

SC21  N  8063 

SC21  N  8064 

SC21  N  8065 

SC21  N  8127 
SC21  N  8282 
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Proposal  for  an  NWI:  Conceptual  Schema  Modelling  Facility,  August  1993  [SC21  N  8060,  June 
1993]  (balloting  ended  in  November  1993)  (WD  expected  July  1995.  CD  July  1996,  MS  July  1997, 
and  IS  July  1998) 

Summary  of  Voting  on  Document  JTC1  N  2621,  Proposal  for  a  New  Work  Item:  Conceptual  Schama 
Modelling  Facility,  December  1993 

Report  from  ISO/IEC  JTC1/SC21  Chairman  on  Activities  Related  to  Application  Program  Interfaces 
(APIs)  and  Modelling  Facilities  (MFs),  January  1994 
SC21  SWG-MF  Meeting,  June  1993,  Yokohama.  July  1993 

Recommendation  to  Progress  Work  on  the  Use  of  Standard  Data  Modelling  Facilities  in  the 
Preparation  of  International  Standards,  SWG-MF,  July  1993 

Final  Recommendations  of  the  SC21  Special  Working  Group  on  Modelling  Facilities  (SWG-MF), 
SWG-MF,  July  1993 

Response  to  the  SC21  Chairman  from  the  SC21  Special  Working  Group  on  Modelling  Facilities 
(SWG-MF),  SWG-MF,  July  1993 

SC21  Special  Working  Group  on  Modelling  Facilities  (SWG-MF)  Response  to  ISCVIEC  JTC1/SC18 
Liaison  Statement,  SWG-MF,  July  1993 

SC21  Special  Working  Group  on  Modelling  Facilities  (SWG-MF)  Liaison  Statement  to  ISCVIEC 
JTC1/SC14.  SWG-MF,  July  1993 

SC21  Special  Working  Group  on  Modelling  Facilities  (SWG-MF)  Response  to  ISO/IEC  JTC1/WG3 
Open  edi  Liaison  Report,  SWG-MF,  July  1993 

SC21  Special  Working  Group  on  Modelling  Facilities  (SWG-MF)  Response  to  ISO/TC46/SC4 
Liaison  Statement,  SWG-MF,  July  1993 

SC 21  Special  Working  Group  on  Modelling  Facilities  (SWG-MF)  Response  to  JTCI/SC21/WG7 
Liaison  Statement,  SWG-MF,  July  1993 

Liaison  Information  on  Modelling  Facility  Interim  Work,  SC21  SWG-MF,  June  1993 

Calling  Notice  and  Draft  Agenda  for  the  Interim  Meeting  of  the  SC21/WG3  Rapporteur  Group  on 

Conceptual  Schema  Modelling  Facilities,  Aix  en  Provence,  17-21  January  1994,  October  1993 
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UNCLASSIFIED 


UNCLASSIFIED 


SC21NS303 
SC21/W03  N  1644 

SC21/WG3  N  1645 
SC21  WQ3  N  1646 


A  Data  Modelling  Facility:  JDMF/MODEL-1992,  Japan.  October  1993 

Technical  Report  oa  the  Semantic  Unification  of  Meta-Model,  Volume  1,  Semantic  Unification  of 

Static  Models,  US  Natiooal  Body,  Nnovember  1993 

Knowledge  Interchange  Format  (KIF),  US  Natiooal  Body,  Nnovember  1993 

Propoeed  Working  Draft  for  Base  Document  for  Conceptual  Schema  Modelling  Facilities 


J.  OPEN  SYSTEM  ENVIRONMENT  (OSE)  AND  PROGRAMMING  INTERFACES 


jrrci  N2835 

ITC1N2S36 
SOPS  N  9*3 

SGFSN 1078 

SQFSN  1003 
SGFSN  1043 
SQFSN  1065 
SQFSN  1067 
SQFSN  1069 

SGFSN  1090 
SGFSN  1099 

SQFSN  1098 

SC21  N  8010 
SC21  N  8013 

SC21  N  8109 

SC21  N  8258 

SC21  N  8316 
SC21N8320 
SC21N8397 


Report  from  ISO/IEC  JTC1/SC21  Chairman  on  Activities  Related  to  Application  Program  Interfaces 

(APIs)  and  Modelling  Facilities  (MFs),  January  1994 

JTC1/SC21  Reports  oa  Application  Program  Interfaces  (APIs).  January  1994 

UK  Discussion  Paper  Relating  to  User  Requirements  Relevant  to  Open  Systems  Assessment 

Methodology,  July  1993 

Draft  Guide  to  the  POSDC  Open  System  Environment  (P1003.Q/D16.1),  IEEE  Computer  Society, 
Deostahsr  1993 

Modification  of  SD-1,  SGFS  Procedures,  for  Adoption  of  PTSs  and  APIs,  August  1993 
Liaison  StaWmeot  to  SGFS  aod  EWOS/EG-OSB,  OIW,  November  1993 
US  Comments  on  OIW  Liaison  Statement  to  SGFS  aod  EWOS/EG-OSE,  August  1993 
Listen  Statement  to  SC21/SWG-PS,  SGFS,  December  1993 

White  Paper  on  OSE  Profiling  Concepts,  SGFS,  December  1993  (raatericl  offered  for  integration  in 
ISO/IEC  TR  10000) 

Liaieon  Statement  to  JTC1  on  the  Subject  of  PAS  and  APIs,  December  1993 

Draft  Minutes  of  the  SGFS  Authorized  Subgroup  Meeting  in  Amsterdam,  29  November  to  3 

December  1993,  SGFS,  December  1993 

Raeolutions  Adopted  by  the  SGFS  Authorized  Subgroup  Meeting  in  Amsterdam,  29  November  to  3 
December  1993,  SGFS.  December  1993 

Proposal  for  an  NP  on  Open  Systems  Assessment  Methodology,  July  1993 

Listen  Statement  to  J7C1/SWG-CA,  JTC1/SGFS,  EWOS,  OIW,  and  AOW  oa  Open  Systems 

Assessment  Methodology,  August  1993 

Proposed  New  Question  Q3/011,  ‘‘Harmonization  of  Client/Server  Capabilities,”  SC21/WG3, 
September  1993 

Cosroctad  Liaison  Statement  to  SC21  Entitled,  “Comments  on  the  First  Draft  Report  on  the  New 

Wmk  Ana  on  Programmatic  Interfaces,”  SC18.  October  1993 

Commfana  on  Standardized  Programmatic  Interfaces,  USA.  October  1993 

UK  Position  on  Programmatic  Interface  Standardization.  UK,  November  1993 

Outline  Contribution  to  Future  Work  as  Proposed  in  SC21  N  8045  Rev  2.  SC21  SWG-SPI  Meeting 

8-11  November  1993  in  Torina,  January  1994 
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UNCLASSIFIED 


IL  LAYER  1:  PHYSICAL  LAYER1* 

A  General 

B.  Mechanical 

C.  Functional 

D.  Procedural 

E.  Local  Area  Networks 

A.  GENERAL: 

STAN  AG  4251*  NATO  Reference  Model  forOSI  -  Layer  1  (Physical  Layer)  Service  Definition.  Draft 

STAN  AG  4261*  NATO  Raftrance  Model  (or  OSI  -  Layer  1  (Physical  Layer)  Protocol  Specification,  Draft 

ISO  6951  Ubnutiog  Processing  •  Processor  System  Bos  Interface  (Enrobes  A) 

ISO  9160  Physical  Layer  Interoperability  Requirements 

ISO  9316  Small  Computer  System  Interface  (SCSI) 

DIS  9318-1  lesentymt  Peripheral  Interface.  Part  1:  Physical  Level 

ISO  9318-2  Intelligent  Peripheral  Interface,  Part  2:  Device  Specific  Command  Set  far  Magnetic  Disk  Drives 

ISO  9318-3  Intelligent  Peripheral  Interface.  Part  3:  Qw<«>  ft— <<■  >*■■■■■'■  it  s«e  far  u«p«fc  -t  ryiwi  m* 

Drives 

ISO  9318-4  IntelUgent  Peripheral  Interface,  Part  4:  Device  Getieric  Command  Set  for  Magnetic  Tape  Drives 

US  9324  Storage  Module  Interfaces 

ISQflEC  10022s  Physical  Service  Definition  (X.211) 

DIS  10322  Enhanced  Snudl  Device  Interface 

riU-TS  V.7e  DefinMou  of  Terms  Concerning  Data  Communication  over  Telephone  Network 

ITU-TS  X.211  Physical  Service  Deflnitioo  of  OSI  for  COTT  Applications  (ISO  10022) 

’  ITU-TS  X.281  Element*  or  Management  Information  Related  to  the  OSI  Physical  Layer  (ISO  13642).  Draft,  1993 

B.  MECHANICAL: 

ISO  2110s  23-Pin  DTE/DCE  Interface  Connector  and  Pin  Assignments 

AMI  Interface  Counselor  and  Contact  Number  Assignments  far  a  DTE/DCE  to 

Data  Signalling  Rates  Above  20  kbit/s 

ISO  2593:1984s  34-Pin  DTE/DCE  Interface  Connector  and  Phi  Assignments 

ISO  4902s  37-Pin  DTE/DCE  Interface  Counertor  and  Pin  Assignments 

ISO  4903s  15-Pin  DTE/DCE  Interface  Connector  and  Pin  Assignments 

ISCVTR  7477s  Anangantmts  for  DTE/OTE  Physical  Connection  Using  V.24  and  JL24  Interchange  Ckcuitt 

ISO  8481s  'DIE/DTB  Physical  Conaectioa  Using  X34  Interchange  Circeita  with  DIE-Itovidsd  Timing 

ISOABC  8877s  Interface  Connector  and  Contact  Assignments  for  ISDN  Basic  Accees  Interface  LoraWd  at  Reftrvci 
Points  S  andT 

AMI  Standard  ISDN  Basic  AooaasTECouneclh^  Coed 

ISQflEC  10173s  ISDN  Primary  Access  Connector  at  Reference  Points  S  and  T 

ISOflBC  11569  26-Pole  Interface  Connector  Mataability  Dimensions  and  Contact  Number  Assignments,  1993 
CD  11573  Synchronisation  Methods  and  Technical  Requirements  for  Private  integrated  Services  Networks 

CD  11574  Private  Integrated  Services  Network  •  Circuit  Mode  64  kbit/s  Bearer  Services  •  Service  raflnitinii  • 

Functional  Capabilities  and  Information  Flows 
mj-TSL340  ISDN  Connection  Types 

C.  ELECTRICAL: 

ISO  8482s  TViated  Pair  Multipoint  Interconnections 

1909549s  Galvanic  Isolation  of  Balanced  Interchange  Circuits.  October  1990 

ITU-TS  Q.700s  Signaling  System  No.  7  (SSI)  Overview 

ITLl-TS  Q.701-Q.710S  Signaling  System  No.  7  (SSI)  Massage  Tramfar  Part 

ITU-TS  Q.7U-Q.716S  Signaling  System  No.  7  (SSI)  Signalling  Cocacctioo  Control  Part  (SCCP) 

ITU-TS  Q.720-Q.729s  Signaling  System  No.  7  (SS7)  Telapbone  User  Part  (TUP) 


19  The  symbol  e  is  used  throughout  this  appandis  to  identify  thorn  standards  included  in  the  Saptaaabar  1993  NOSIP 
Strategy. 
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UNCLASSIFIED 


UNCLASSIFIED 


ITU-TS  Q.730-Q.739*  Signaling  System  No.  7  (SS7)  ISDN  Supplementary  Service* 

ITU-TS  Q.760-Q.769*  Signaling  Sy*Um  No.  7  (SS7)  Deacriptioo  of  the  ISDN  Uier  Pert  (IS UP) 

ITU-TS  Q.770-Q.779*  Signaling  System  No.  7  (SS7)  Treiuactinn  Capabilities  (TC) 

ITU-TS  VS  Data  Signalling  Rales  for  Synchronous  Data  Transmission  in  the  General  Switched  Telephone 

Network 

ITU-TS  V.6  SI |M»ing  fnr  Synchronons  TVenemkrinn  on  ImmH  Tciephonc-Type  firenin 

ITU-TS  V.13  Simulated  Carrier  Control 

ITU-TS  V.14  Transmission  of  Start-Stop  Characters  over  Synchronous  Dearer  Channels 

IIU-TS  V.17  A  2-wire  Modem  for  Facsimile  Applications  with  Data  Signaling  Rates  of  op  to  9.600  bit/s  for  Use 

on  the  General  Switched  Telephone  Network  and  on  Leaned  Telephone-Type  Circuits 
ITU-TS  V32  bis  A  Duplex  Model  Operating  at  Data  Signalling  Rates  of  np  to  14,400  bit/s  for  Use  on  the  General 
Switched  Telephone  Network  and  on  Leased  Point -to- Point  2-wire  Telephone- Type  Circuits 
ITU-TS  V 38  A  48/56/64  kbit/s  Data  Circuit  Terminating  Equipment  Standardized  for  Uae  on  Digital  Point-to- 

Point  Leased  Circuits 

ITU-TS  V.42  Rev  1  Error-Correcting  Procedures  for  DCEs  Using  Asynchrooous-to-Synchronous  Conversion 


ITU-TS  V.42  Ms  Data  Compression  Procedures  for  Data  Circuit  Terminating  Equipment  (DCE)  Using  Error  Correcting 
Procedures 


D.  FUNCTIONAL: 

ISCVIEC  7480*  Start-Stop  Transmission  Signal  Quality  at  DTE/DCE  Interfaces,  Second  Edition 

ISO  9543*  Synchronous  Transmiesioa  Signal  Quality  at  DTE/DCE  Interfaces 

ITU-TS  L4I1  Rev  1  ISDN  User-Network  Interfaces— Reference  Configuration 

ITU-TS  L412  ISDN  User-Network  Interfaces — Interface  Structures  and  Access  CapebUlties 

ITU-TS  X.l  Rev  1«  International  User  Qasaes  of  Service  in  Public  Data  Networks  and  Integrated  Services  Digital 
Networks  (ISDNa) 

ITU-TS  X2  Rev  1  International  Data  lYansmisskn  Services  and  Optional  Uier  Facilities  in  Public  Data  Networks  and 
ISDNa 

ITU-TS  X3  Rev  1  Packet  Aaaembly/DUaeaeinbly  Facility  (PAD)  in  a  Public  Data  Network  (PDN) 

ITU-TS  X.4  General  Structure  of  Signals  of  International  Alphabet  No.  3  Code  for  Data  Transmission  over 

Public  Deta  Networks 

ITU-TS  X3  Facsimile  Packet  Asaembly/Disaseetnbty  Facility  (FPAD)  in  a  Public  Data  Network 

ITU-TS  X. 6  Multicast  Service  Definition 

ITU-TS  X7  Technical  Characteristics  of  Data  Transmission  Services 

ITU-TS  X.  10*  Categories  of  Access  for  DTE  to  Public  Data  Transmission  Services  Provided  by  PDNs  and/or  ISDNs 

through  Terminal  Adaptors 

ITU-TSX24*  List  of  Definitions  far  Interchange  Circuits  Between  DTE  end  DCE  on  Public  Deta  Networks 

ITU-TS  XJ6/V.10*  Electrical  Characteristica  for  Unbalanced  Donble-Cnmnt  Interchange  Circuits  for  General  Use  with 
Integrated  Circuit  Equipment  in  the  Field  of  Data  Communications 
ITU-TS  X.27/V.U*  Electrical  Chatncttfietici  for  Unbalanced  Double-Currant  Interchange  Circuits  for  General  Use  with 
Integrated  Circuit  Equipment  in  the  Held  of  Data  Communications 
ITU-TS  X. 28  Rev  1  DTE/DCE  Interface  for  a  Start/Stop  Mode  DTE  Accessing  the  PAD  in  a  PDN  Situated  in  the  Same 

Country 

ITU-TS  X.29  Rev  1  Procedures  far  the  Bichange  of  Control  Information  and  User  Data  Between  a  PAD  Facility  and  a 
Packet  Mode  DTE  or  Another  PAD 

ITU-TS  X3M.461  Support  of  X.21.  X31  bis.  and  X20  bis  Based  Data  Terminal  Equipment's  (DTEs)  by  an  Integrated 
Services  Digital  Network  (ISDN) 

ITU-TS  X31/L462  Rev  U  Support  of  Packet  Mode  Terminal  Equipment  by  an  ISDN 

ITU-TS  X38  03  Facsiudla  Equipment/DCE  Interface  for  03  Facsimile  Equipment  Accessing  the  Facsimile  Packet 

Assambiy/DieasasmMy  Facility  (FPAD)  in  a  Public  Data  Network  Situated  in  the  Same  Country 
ITU-TS  X39  Procedures  for  the  Exchange  of  Control  Information  and  User  Data  Between  a  Facsimile  Packet 

AeeemMy/Die— emhly  (FPAD)  Facility  and  a  Packet  Mode  DTE  or  Another  FPAD 
ITU-TS  X30  Fundamental  Parameter*  of  a  Multiplesing  Scheme  for  the  International  Interface  Between 

Synchronous  Data  Network! 

ITU-TS  XiOMs  Fundamental  Proitan  of  a  4«-kbit/»  Uier  Deta  Signalling  Rate  Tranmueekm  Scheme  for  the 
International  Interface  Between  Synchronous  Data  Network* 

ITU-TS  XJl  Fundamental  Penmater*  of  a  Multiplexing  Scheme  for  the  International  Interface  Between 

Synchronous  Data  Networks  Using  10-bit  Envelope  Structure 

ITU-TS  X31Ms  Fundamental  Parameters  of  a  48-kbit/s  User  Data  Signalling  Rate  Transmission  Scheme  for  the 
Intametionel  Interface  Between  Synchronous  Date  Using  10-bit  Envelope  Structure  Network* 
ITU-TS  X32  Method  of  Encoding  Anteochronou*  Signal*  into  a  Synchtonon*  U*e  Banter 

nU-TS  X33  Rev  1  Nnmbering  of  Chroneh  on  International  Multiplex  tinki  at  64  kbR/i 

ITU-TS  X34  Alocntion  of  Ch— ell  on  International  Multipin  Link*  at  64  kbit/* 

ITU-TS  X53  Interim*  Between  Syneiwuou*  Date  Network*  Using  a  6  ♦  2  Envelope  Structure  and  Single  Channel 

Per  Cantor  (SCPC)  SateUte  Channels 
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rru-Tsx.56 

mj-TSX57 

UU-TSX5S 

rru-Ts  x.6o 
ITU-TS  X.61/Q.741 
rru-Ts  x.7o 


mj-TSX.7t 
ITU-TS  X. 75  Rev  U 
rru-Ts  x. 7* 
rru-xs  x jo 

ITU-TS  XJ1 

rru-xs  XJ2 

ITU-TS  X.92 
ITU-TS  X.96  Rev  1 
ITU-TS  X.I21 
ITU-TS  X. 122/E. 166 
ITU-TS  X.  130 

rru-Ts  x.  i3i 

ITU-TS  X.134 

ITU-TS  X.  135 

ITU-TS  X.136 

ITU-TS  X.  137 

ITU-TS  X138. 

ITU-TS  X.  139 

rru-Ts  x.  140 
nru-Ts  x.iso 

ITU-TS  X.1S1 
ITU-TS  XJx 


ITU-TS  X.eep 
ITU-TS  Xx»p+ 
rru-Tsx.au: 

ITU-TS  XAq 

ITU-TS  XJhi 

ITU-TS  XJsp 
ITU-TS  Xjmp 
ITU-TS  Xjncp 

rru-Ts  Xmcp* 


ITU-TS  X  jape 


Interface  Between  Synchwaoee  Data  NetewdtaUaiag  an  S+2  Envelops  Sauctam  an d  Slagle  Chaaa el 
Per  Carrier  (SCPC)  Satellite  Oiweirli 

Method  of  nanamittiiig  a  Single  Lower  Speed  Data  Channel  oa  e  64  kUM  Data  Stream 
Fundamental  Parameter!  of  a  Multiplexing  Scheme  for  the  International  Interface  Between 
Synchronous  Noo-Switched  Data  Networks  Using  No  Envelope  Structure 
Common  Channel  Signalling  for  Circuit  Switched  Data  Applications 
Signalling  System  No.  7  -  Data  Uaer  Part 

Terminal  and  Transit  Control  Signalling  System  for  Start-Stop  Services  on  International  Circuits 
Between  Anisochrooous  Data  Netwarics 

Decentralized  Terminal  sod  Transit  Cootrol  Signalling  System  on  International  Circuits  Between 
Synchronous  Deta  Networks 

Packet-Switched  Signalling  System  Between  Public  Networks  Providing  Deta  Transmission 
Services,  1993 

Signalling  System  Between  Public  Networks  Providing  name  Relaying  Deta  Transmissions! 
Services,  Draft,  1993  (approval  data  November  1994) 

Interworking  of  Interexchange  Signalling  Systems  for  Circuit  S notched  Data  Services 
Interworking  Between  an  ISDN  Circuit  Switched  and  a  Circuit  Switched  Public  Data  Network 
(CSPDN)  _ 

Detailed  Arrangements  for  Interworking  Between  CSPDNs  and  PSPDNs  Baaed  on  Recommendation 
T.70 

Hypothetical  Reference  Connections  for  Public  Synchronous  Data  Networks 
Call  Progress  Signals  in  Public  Deta  Networks 
International  Numbering  Plan  for  Public  Data  Networks 
Numbering  Plan  Interworking  for  the  W.164  and  X.121  Numbering  Plane 

Call  Processing  Delays  in  Public  Data  Networks  when  Providing  International  Synchronous  Circuit- 
Switched  Deta  Services 

Call  Blocking  in  Public  Data  Networks  when  Providing  International  Synchronous  Circuit-Switched 
Deta  Services 

Portion  Boundaries  and  Packet  Layer  Reference  Events:  Basis  for  Defining  Packet-Switched 
Performance  Parameters 

Speed  of  Service  (Delay  or  Throughput)  Performance  Values  for  Public  Data  Networks  when 
Providing  International  Packet-Switched  Services 

Accuracy  and  Dependability  Performance  Values  for  Public  Data  Networks  whan  Providing 
International  Packet-Switched  Services 

Availability  Performance  Values  for  Public  Data  Networks  when  Providing  International  Packet- 
Switched  Services 

Measurement  of  Performance  Values  for  Public  Data  Networks  when  Providing  Intarnatinual  Packet- 
Switched  Services 

Echo,  Drop,  Generator  and  Test  UTS's  for  Measurement  of  Performance  Values  for  Public  Data 
Networks  when  Providing  International  Packet-Switched  Services 
General  Quality  of  Service  Parameter  for  Communication  Via  Pubtic  Data  Networks 
Administrative  Arrangements  for  International  Closed  User  Groups  (CUGs) 

Administrative  Arrangements  for  the  Provision  of  International  Permanent  Virtual  Circuits  (PVCs) 
Access  to  Packet  Switched  Data  Transmission  Services  Provided  by  PSPDN  or  ISDN  via  Frame 
Relaying  PDNs  or  ISDN  Providing  Frame  Mode  Bearer  Service.  Draft.  1993  (approval  target 
November  1994) 

Multi-Aspect  PAD  Protocol  Definitions- 1,  Draft,  1993  (approval  target  November  1994) 
Multi-Aspect  PAD  Protocol  Definitions-2,  Draft,  1993  (approval  target  1996) 

Address  Translation  Capability  in  Public  Data  Networks,  Draft,  1993  (approval  target  November 
1994) 

User  Information  Transfer  Parameters  and  Specifications  for  Data  Networks  Providing  International 
Frame  Relay  PVC  Service,  Draft,  1993  (approval  date  November  1994) 

Interface  Between  DTE  and  DCE  for  Public  Data  Network  Proving  Frame  Relay  Data  Tranamiasioo 
Service,  Draft,  1993  (approval  target  November  1994) 

Intar-Service  Protocol  for  a  Multicast  Service,  Draft,  1993  (approval  target  June  1995) 

Multi-Aspect  PAD  Framework,  Draft,  1993  (approval  target  Primary  1994) 

Procedures  for  the  Provision  of  a  Basic  Multicast  Service  for  DCBs  Operating  Using 
Recommendation  ITU-TS  X.2S,  Draft,  1993  (approval  target  November  1994) 

Procedures  for  the  Provision  of  an  Enhanced  Multicast  Service  for  DCEs  Operating  Usb* 
Recommendation  ITU-TS  X.25  and  Requiring  Additional  Protocol,  Draft,  1993  (approval  target 
1996) 

Encapsulation  in  ITU-TS  X.2S  Packets  of  Various  Protocols  Including  Frame  Relay,  Draft,  1993 
(approval  target  November  1994) 
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B.  PROCEDURAL: 

ISO  >480  DTE/DCE  Back-Up  Control  Operation  Using  the  25-Pole  Counselor 

ISO  9067  Automatic  Fault  Isolation  Procedures  Using  Test  Loop* 

1TU-TSL420  Banc  User-Network  Interface  (ISDN) 

ITU-TS  L42I  Primary  Rata  Uaer-Network  Interface  (ISDN) 

ITU-TS  L430  Rev  1  Baric  User-Network  Interface — Layer  1  Specification  (ISDN) 

ITU-TS  1431  Rev  1«  Prinury  Rale  User-Network  Interface  Layer  1  Specification  (ISDN) 

ITU-TS  1432  Rev  U  B4SDN  Network  Interface— Physical  Layer  Spadfieatioa 

ITU-TS  L460*  Muhiplcxiag.  Rata  Adaptation  aod  Support  of  Existing  Inrirfacea  (ISDN) 

ITU-TS  L461*  Support  of  X.21,  X.21  bis,  and  X.20  bit  Baaed  DTE»  by  an  ISDN  (X.30) 

ITU-TS  1462*  Support  of  Packet  Mods  Tsrminel  Bquipeeset  by  se  ISDN  (XJ1) 

ITU-TS  L463*  Support  of  DTEi  with  V -Series  Type  Interface*  by  «n  ISDN 

ITU-TS  L464«  Mahipkxtng.  Rate  Adaptation,  and  Support  of  EiMn  larirfacat  for  Rariricled  64  kbit/i  Traasfer 

Capability 

TTU-TS  L463  Support  by  aa  ISDN  of  DTE*  with  V -Series  Type  Interfaces  with  Provisions  far  Statistical 

Multiplexing 

ITU-TS  1470  Rejatjouridp  of  Tbnuiaal  Functions  to  ISDN 

m)-TSV.l(MX.a6«  Electrical  Characteristics  far  Uabalaaced  Double-Caoeat  Interchange  Circuits  far  Oeaeral  Use  with 
IatsgnMed  Oscuit  Equipment  ia  the  Reid  of  Data  Communication 
ITU-TS  V.l  1/X.27e  Electrical  Cheractaririice  far  Balanced  DouMe-Conem  Interchange  Cbcuite  far  General  Use  With 

ITU-TS  V  JO  Telex  aad  Oeatex  Signalling  oa  Radio  Chaaaris  (Syaduoaone  7 -Unit  Systems  Affording  Error 

Comctioa  by  Automatic  Repetition) 

ITU-TS  VJ4e  List  of  Deflnitioos  far  Interrbsnge  Circuits  Between  DIE  and  DCE 

ITU-TS  V  JS  Automatic  Answering  Equipment  and/or  Parallel  Automatic  Calling  Equipment  on  the  General 

Switched  Telephone  Network  Including  Procedures  far  Disabling  of  Echo  Control  Devices  far  Both 
Manually  and  Automatically  Established  Calls 

IIU-TS  VJSRev  le  Electrical  CharactetiUca  far  Unbalanced  DouMe-Cunant  lutsrrhsngs  Ctrcnita 

ITU-TS  V  J1  Electrical  Characriristice  for  Siugle-CURaat  Interchange  Orcuita  Controlled  by  Contact  Closure 

ITU-TS  V31  bis  Electrical  Charactmietics  far  Sagte-Cunant  Interchange  Chcuhe  Using  Opto  Couplers 

IIU-TSVJSe  Data  Trwsmfcrion  at  4>khWs  Using  60-10S  Mb  Group  Band  Otcuite 

ITU-TS  VJ6e  Modems  for  Synchronous  Data  Traosmiarioe  Using  6O-10>  kHz  Gronp  Band  Oreuits 

ITU-TS  V37s  Synchronous  Data  Thatmrission  at  a  Data  Signalling  Rate  Higher  than  72  kbit/s  Using  60-108  kHz 

Group  Band  Circuits 

ITU-TS  VJ4  Loop  Teat  Devices  far  Modems 

ITU-TS  XJO  Rev  1  lutsrftcs  Bstwusu  DIB  and  DCE  far  Start-Stop  Trsuemlssinn  Services  on  Public  Data  Natwnsfca 
ITU-TS XJOMs  Use  an  Public  Butt  Networks  of  DTE  Which  Is  Designed  for  Interfacing  to  Asynchronous  Duplex 
V -Series  Modems 

ITU-TS  XJU  Interfere  Between  DTE  sad  DCE  far  Synchronous  Oparatioe  on  Public  Data  Networks 

ITU-TS  X.21  bie*  Uae  oa  Public  Data  Networks  of  DTE  Which  Is  Designed  for  Interfacing  to  Synchronous  V-Series 

ITU-TS  XJ2  Multiplex  DTE/DCE  Interface  far  Usw  Claesm  3-6 

ITU-TS  XJ1  Rev  1«  Suppost  of  Packat  Mode  Terminal  Equipment  by  m  ISDN 

ITU-TS  X32  Rev  1«  Intwfaoe  Between  DTE  and  DCE  for  Terminals  Operating  in  foe  Packet  Mode  and  Accessing  a  Packet 

Switched  PDN  Through  a  Public  Switched  Telephone  Network  or  a  Orcoit  Switched  PDN 
ITU-TS  X.  130  Prindpha  of  Milnlanaari  Testing  far  PuhBc  Data  Networks  Using  DTE  end  DCE  Teat  Loops.  19M 

ITU-TS  X.  160  Arcfahectore  far  Customer  Network  Management  Services  far  Pnbhc  Data  Networks.  Draft.  1993 

ITU-TS  X.  161  Definition  of  Customer  Network  Management  Services  far  Public  Data  Networks,  Draft.  1993 

ITU-TS  X.  162  Definition  of  Man  age  meat  Informaton  far  the  Customer  Network  Management  Services  for  Public 

Data  Networks,  Draft,  1993 


F.  LOCAL  AREA  NETWORKS  (LANa)t  . 

me  >47  Characteristics  of  LANs,  19S8 

IEC/TR  907  Local  Area  Networks  CSMA/CD 10  Mbit/s  Baseband  Planning  and  Installation  Guide 

ISO  MQ2-1*  LANs,  Put  1:  General  Introduction 

US  M02-1.2  LANs,  Part  1:  General  Introduction  with  System  Load  Protocol 

ISO  M02-2*  LANs.  Part  2:  Logical  Link  Control 

US  008-2.2  LANs,  Part  2:  Logical  Lta*  Control,  EdUon  2 

Cor  1  Technical  Corrigendum  1 

DAM  1  Flow  Control  Techniques  for  Bridged  LANs 

DAM2  Type  3  Operation  -  Acknowledge  Connectionless  Service 

DAM  3«  PICS  Proforma 

DAM4  Editorial  Changes  aod  Technical  Corrections 
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FOAMS  Bridged  LAN  Source  Rooting  Oparatioas  by  Ead  Systems 

ISQ/IEC 8802-3*  LANs,  Pat  3:  Cmrier Same Mnfaipi* Access  with Coflisiou DOaha (CSMA/CD) - Aoc—  Method 
aad  Physical  Layar  Specifications 

DAM  6  Sonaary  of  IEEE  M&3  Pint  Mainteaace  Ballot 

DAM  7  LAN  Layer  Management 

DAM9  TWistod  Pair.  Modiom  Attachment  Unit,  aad  Baaobaad  Madina 
Spaciflcadoa*.  Type  1  OB  ASET 
PDAM11  Hob  Management,  March  1992 

PDAM 13  Attachment  Unit  Interface  Cable  Conformance  Test,  Macb  1992 
FOAM  IS  Conectioos  and  Updates  2  A  3,  Mach  1992 

PDAM  17  PICS  Proforma  for  10  BASE-T,  Mach  1992 

ISCVIEC  8802-4*  LANs,  Part  4:  Token-Passing  Bus  Access  Method  aad  Physical  Layar  Speriflcalinns 

ISCVIEC  8802-5*  LANs.  Part  5:  Token  Ring  Access  Method  sad  Physical  Layer  Specifications 

DiS  8802-6*  LANs.  Part  6:  Distributed  Queue  Dual  Bus  (DQDB)  Media  Access  Cootrol  (MAC) 

ISCVIEC  8802-7  LANs,  Part  7:  Slotted  Ring  Access  Method  sod  Physical  Layar  Specification 

DiS  8802-9*  LANs,  Part  9;  Integrated  Voice  md  Data  (IVD)  LAN 

CD  8802-51  LANs.  Part  51.  MAC  Sublayer  Coofatatace  Teet  Pmpoaas 

ISCVIEC  8881*  Use  of  the  X.2S  Packet  Level  Protocol  (PLP)  in  Local  Area  Networks 

ISO  9314-1*  Fiber  Distributed  Data  Interface  (FDD!),  Part  1:  Token  Ring  Physical  Layer  Protocol  (PHY) 

ISO  9314-2*  FDDL  Part  2:  Token  Ring  Media  Access  Cootrol  (MAC) 

ISCVIEC  9314-3*  FDDI,  Put  3:  Physical  Layer  Medium  Dependant  (PMD) 

ISCVIEC  9314-4*  FDDI-Pait  4:  Shigle-Mode  Fibsr/Physical  Layer  Modfami  Dependent 
DIS  9314-3*  FDDi-Pm  5:  Hybrid  Ring  Control  (FDDi-II) 

CD  9314-6  FDDi-Patt  6:  Station  Management  (SMT)  Standard 

ISCVIEC  HI  9378  Communication  Interface  Connectors  Used  in  LANs 
DIS  10038*  MAC  Sublayer  Interconnection  (MAC  Bridging) 

PDAM1  Specification  of  Management  Information  for  CMIP 
DAM  2  Source  Routing  Supplement 

ISCVIEC  10039*  MAC  Service  Defmitioo 

ISCVIEC  TR  10178  Structure  sad  Coding  of  Link  Service  Access  Pohit  Addresses  in  LANs 

ISCVIEC  TR  10738  Token  Ring  Access  Method  mi  Physical  Layer  Specifications  -  Practice  for  Use  of 

Unshielded  Twisted  Pair  Cable  (UTP)  for  Token  Ring  Data  Trmanriarioa  at  4  Mbitfs.  1993 
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HL  LAYER  2&  DATA  LINK  LAYER** 


A.  Ganaral 

B.  Charactor-Oriantad  Saivfca  (Baaie  Mod*) 

C.  BO-Oriantad  Saivie*  (HDLC  Procaduraa) 

D.  W'togratad  Sarvfca*  Digital  Natwork  (ISON) 

E.  Errtr  Conaction  and  Contamanca  Taat  Suite 


A.  GENERAL: 


STANAG4232* 
STAN  AO  4263* 
ISO  MM* 
ISOABCTR  10171* 


US  10742 

SC21N4346 
1TU-TS  X.212 
itu-ts  x.2S2 


NATO  Rak-aca  Modal  for  OSI  -  Lag—  2  (Data  Uak  Lag—)  Santos  DaAaiti— 

NATO  RaCaaaes  Modal  for  OSI  •  Lag—  2  (Data  Uak  Lag—)  ftotoool  Spsdfiesd— 

Dau  Uak  Service  DaMtioa  for  OSI 

Liat  of  St-d-d  Data  Lkfc  Lag—  ftotocok  tat  UtlHaa  HDLC  Oaaaaa  of  Broeadm 

FDAM1  Kagtotradoa  of  XID  Fonaat  Id— dflata  aad  Prhrata  hwaata  Sat 
Idsadfisti 

Spadficadoa  of  l ha  Bla— aata  of  II— ipaanai  Iaformatloa  Bafadad  to  OSI  Data  Uak  Lag— r 
St— dank.  1993 

Uak—  Tta— n—t  la  JTC1/SC21  oa  Data  Uak  Lag—  Sacarity 

Data  Uak  Santoe  Defioki—  of  OSI  for  CdTT  AppUcado—  (ISO  0096k  190S 

El—  of  M— agaa—M  Iaftamadoa  RMakd  to  ta  OSI  Data  LMc  Lag—  (BO  10742),  Dnft.  1993 


B.  CHARACTER-ORIENTED  SERVICE  (BASIC  MODE): 

ISO  1155  (1—  of  Loagtadiaal  Parity  to  Datact  Etna  k  Iafcma d—  Massagaa 

ISO  1177  a— at—r  Streets—  for  Start/Stop  aad  Syackv— o—  Cbaractor  Oak— ad  Tnaa—ksfca 

ISO  1743  Baalc  lioda  Control  Ptored—ai  for  DkaCnaa— alrallna  Sg— 

ISO  2111  Baalc  Koto  Control  fwoadaaaa  -  Ooda  latop— itad  Mnnaartna  Tk-atot 

ISO  2620  Baatc  Moda  Coatrol  ftoesdaras  •  Co— pk— sals 

ISO  2629  ■^L.u^./^jfYrTftTrrT  n . '■■■'  Tafiaaialhia  llaaa^a  Tl— afa 


C.  BIT-ORIENTED  SERVICE  (HIGH-LEVEL  DATA  LINK  CONTROL  PROCEDURES 
(HDLC)): 


ISO  3309:19*4* 
ISO  3309:1991 


ISO  4333:1904* 
ISO  4333:1991 


ISO  7470* 
ISO  7776* 


190  7109:1904* 
ISO  7009:1991 


190  0471* 


HDLC  -  Fra  Stnctna.  BdMoa  3 
HDLC  -  i¥a— a  Stnetaaa,  BdM— 4 

AM2  Bnaadad  Traaaparaary  PgUp—  fcr  Start/Stop  TV— — laaira 

PDAM3  Savaa-Mt  Tr— apar— cgr  Opdo—  far  Start/Stop  Tfcaaaaaiaai— 

HDLC  -  Bkaaa-a  of  Ptoeadana.  BdW-  3 
HDLC  -  Bkaaaata  of  Prooadaaas,  EdM—  4 

AM  4  Row  Coakol  U— a— bared  Indore— d—  (TOD 

HMDS  MaM-Satocdre  Kajact 

ifcmm 

Cor  1  Tacfcaieal  Coadtaada—  1 

HDLC  -  Daacripd—  of  tka  7L23  LAFB-Ci— padhli  DTE  Da—  Uak  ftocad—at 
Cor  1-3  Tockdeal  Conic— da  1-0 

AMI  Crafor— na  lagaka— 

HDLC  -  Co— oBdad-  of  d-aw  of  Pram  dans,  BdM —  1 
HDLC -Co— oBdad—  ofdaaa—  ofProoadara a.  BdW—  2 

AM3  Cob— cdoala—  da-  of  f-oad-a 

AM6  Bxkadad  Tranap— —cgr  Opd— 

AM  7  Makl  7»ki Ilia  Bijart 

FOAM  9  Sore a  bit  Tr— spare acy  Opd—  tor  Start/Stop  Tr— rek— tea 

HDLC  Balaaead  O-a-  of  Prooadoaw  •  Data  Uak  Lag—  Adtkwa  Kaaotodoa/  Napotkatoa  la 

Swkckad  Darkoa— red 


TO*  symbol  «  k  aood  tto—fhoot  thk  appaadfat  to  kkatify  thoaa  ataad— k  iachadad  ia  Dm  fagtoaihir  1993  MOW 

Stratify. 
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UNCLASSIFIED 


UNCLASSIFIED 


ISO  88SS:1987« 
ISO  1885:1991 


US  9234 
ITU-TST.7U 


HDLC  -  General  Puipoae  XID  Frame  Information  Field  Content  and  Format,  Edition  1 
HDLC  -  General  Purpose  XID  Frame  Information  Field  Content  aod  Format,  Edition  2 

AM  3  Definition  of  a  Private  Parameter  Negotiation  Data  Link  Layer  Sob  field 

AM  4  Emended  Tranapareocy  Option 

AMS  Multi-Selective  Reject 

FOAM  6  Seven-bit  Tranapareocy  Option  for  S tart/Stop  Transmission 

PDAM7  Frame  Check  Sequence  Negotiation  Using  the  Parameter  Negotiation 

SobfMd 

Industrial  Asynchronous  Data  Liak  for  Two-Way  Simultaneous  or  Two-Way  Alternate  Mode 
LAPB  Emended  for  Half-Duplex  Physical  Level  Facility 


D.  INTEGRATED  SERVICES  DIGITAL  NETWORK  (ISDN): 

rm-TSL440v  ISDN  User-Network  latarfoce  Data  Link  Layer— General  Aspects 

mj-TS  L44U  ISDN  User-Network  Imarface  Data  Link  Layer — Specification 


E.  ERROR  CORRECTION  AND  CONFORMANCE  TEST  SUITE: 


ISOABC  8882-2  X.25-DTE  Conformance  Testing,  Part  2:  Data  Link  Conformance  Test  Soke 
DIR  10174  Logical  Link  Control  (Type  2  Operation)  Teat  Purposes 

ITU-TS  X.141  Oansral  Principles  far  the  Deaection  and  Correction  of  Errors  a:  Public  DaU  Networks 
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UNCLASSIFIED 


Data  Link  Layer  Standards 


UNCLASSIFIED 


IV.  LAYER  3:  NETWORK  LAYER*1 


A  Guttural 

B.  Pacfcat-Swttchud  Sutvicu 

C.  Cottnuctiottiuua  Sutvicu 

D.  Integrated  Sotvicos  Digital  Network  (ISDN) 

E.  Routing  and  Rainy 

NNwOnOnp  HQ  n^QnHiRNQ 

Qhtmmfc  CiBnoWniwulnn  Eoufemiont 

KCbettil  StMtidMd  Sutvicu 
I.  Local  Aron  Nutwotfca  (LANu) 


A.  GENUAL: 

STAN  AO  4253* 
STAN  AO  4263* 

ISO  834f« 

ISO  SMS 
ISQABC  MO-1* 
BCMBC  SSSO-2* 


ISCMBCmO-3* 

ISOABC  SMO-4* 

ISOflEC  TR  9377* 
ISOAECTR  10172* 
ISOOBC  10177* 

ISOttBC  10733* 

WD  1077* 

US  11577* 
ITU-TST.70* 
ITU-TS  X.213 
ITU-TS  X.263 
ITU-TS  X. 273 
ITU-TS  X.2S3 


NATO  Rataaoce  Modal  for  OSI  -  Layer  3  (Network  Layar)  Service  Definition 
NATO  Rateaaoe  Modal  for  OSI  -  Layer  3  (Network  Layer)  Protocol  Specification 
Network  Sarvioa  Definition,  Edition  2 
Internal  Organ  aatioo  of  the  Network  Layar.  February  IMS 

— 1  h.  a— <*.  *"TT~*  *“  nK1  *— *"*  ww*  t-  Oawaral  Prindpias 

Protocol  Combination  to  Provide  aad  Support  the  OSI  Network  Service,  Part  2:  Provision  aad 
Support  of  the  Conoectioa-Mode  Network  Service 

DAM  1  Addition  of  the  ISDN  Bnvirnimwt 

PDAM2  AdtSdoo  of  A*  PSTN  and  CSDN  Enviwii— aim 

Protocol  Combination  to  Provide  aad  Support  the  OSI  Network  Service,  Pact  3:  Proviaioa  aad 
Support  of  Ae  Couaectionlerr  Mode  Network  Service 

Protocol  Combination  to  Provide  aad  Support  the  OSI  Networic  Service.  Part  4:  letarrouaartinu  of 
OSI  Buviioamaati 

Protocol  Iilentifli  aha  ia  the  OSI  Network  Laver 
Networfc/Tn— port  Protocol  Iatarworking  Specification 

latanaediele-Symam  Support  of  the  OSI  Couaoctloa  Mode  Network  Service  Uafc*  ISO  S2M  in 
Aooocdaaee  with  BO  1002S 

Specification  of  the  Beamaa  of  llauipimiut  lafarmetioa  Related  to  OSI  Network  Layer  Standard* 
[SC21  N  5560,  SC6  6413] 

High-Speed  Integrated  Service*  Network*  aad  UaatfNetwoak  Interface  to  High-Speed  Integrated 
Service*  Network* 

Network  Layar  Security  Protocol 

Network-bdepaadauf  Baric  Transport  Sarvioa  for  Ae  Telematic  Sarvioa* 

Network  Service  Dafiuition  for  OSI  for  COTT  Applications  (BO  S34S),  19M 
Network  Protocol  Ideutificatiou  Marhaainu  (TR  9577),  Draft,  1993 
Network  Layar  Security  Protocol  (ISO  11377),  Draft,  1993 

Hlameatr  of  Management  Information  Related  to  the  OSI  Network  Layar  (BO  10733).  Draft,  1993 


B.  PACKET-SWITCHED  SERVICE: 


BOS2QS* 


ISO  M7S* 
BOM7S-2 

BOflBCMSl* 
ISOMS2* 
ISQfiBC  MS2-1 
ISOfiBC  SSS2-2 


XJS  Packet  Level  Protocol  (PLP)  for  DTO 

AMI  Altar* ad va  Logical  rhinal  Number  Allocation 

PDAD2  Eateuaioua  for  Private  Switobed  Uae 

AM  3  Static  Conformance  Rsqrinmsnti 

Uea  of  X23  to  Provide  the  OSI  Connection  Mode  Network  Service 
Uae  of  X.23  to  Provide  the  OSI  Connection-Mode  Network  Service,  Part  2:  Protocol 
liaplamaatirinu  Conformance  Statement  (PICS) 

Urn  of  Ae  X  .23  Packet  Level  Protocol  (PLP)  hi  Local  Area  Network! 

X.23-DTE  Conformance  Tatting.  Part  1:  General  Principle* 

X.25-DTE  Cnefnrmann  Testing.  Part  1:  General  Principlw.  BdMon  2  of  BO  MS2 
X.25-DTE  Conformance  Testing.  Part  2;  Data  Link  Couformaace  Teat  Suite 


21  The  symbol  «  ia  need  throughout  Ait  appendix  to  identify  those  ataudard*  included  A  Ae  ftptomlar  1993  NOSIf 
Stratify. 
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UNCLASSIFIED 


UNCLASSIFIED 


1S0ABC  8882-3  X.25-DTE  Conformance  Testing,  Pvt  3:  Packet  Level  Coofoanaace  Test  Sake 
ISOftEC  10388  Use  of  the  X.23  PLP  hi  Conjunction  with  X.21/X.2t  bis  to  Provide  OSI  CONS 

ISO/IEC  10732  Use  of  tbs  X.23  PLP  to  Provide  OSI  CONS  over  Telepbooe  Network 

ITU-TS  X.23  Rev  U  Interface  Between  DTE  and  DCE  for  Tenninals  Operating  in  the  Packet  Mode  and  Connected  to 
Public  Data  Networks  by  Dedicated  Circuit.  19S8  (Revised  Edition,  1993) 

ITU-TSX.75  Rev  1«  Packet-Switched  Signalling  System  Between  Public  Networks  Providing  Data  Transmission 
Services  1988  (Revised  Edition.  1993) 

mJ-TS  X.223  Use  of  X.23  to  Provide  the  OSI  Connection-Mode  Network  Service  for  CCITT  Applications 

(ISO  8878),  1988 

mJ-TS  X.244  Procedure  for  tbs  Exchange  of  Protocol  Identification  During  Virtual  Call  Establishment  on  Packet 

Switched  Public  Data  Networks,  1988 

ITU-TS  X.612  Provision  of  the  OSI  Connection-Mode  Network  Service  by  Packet  Mode  Terminal  Equipment 

Connected  to  an  ISDN.  1992 

C.  CONNECTIONLESS  SERVICE: 

ISO  8473*  Protocol  for  Providing  the  Connection  lest  ■  Mode  Network  Service  (X.233) 

PD  AD  1  Provision  of  the  Underlying  Service  Assumed  by  ISO  8473  over  Point-to- 

Posnt  Subnetworks  Which  Provide  the  OSI  Data  Link  Service 
PD  AD  2  Estelle  Formal  Description  of  ISO  8473 

AD3  Provision  of  the  Underlying  Service  Assumed  by  ISO  8473  over 

Subnetworks  Which  Provide  the  OSI  Data  Link  Service 
PDAM4  PICS  Proforma 

DAM  5*  Provision  of  the  Underlying  Service  Assumed  by  ISO  8473  over  ISDN 
Circuit-Switched  B-cbaonels 
Cor  1  Technical  Corrigendum  1 

DIS  9068*  Provision  of  the  Connectionless  Network  Service  Using  ISO  8208 

DIS  10747*  Protocol  for  Exchange  of  Inter-Domain  Rooting  Information  Among  Intermediate  Systems  to 

Support  Forwarding  of  ISOflEC  8473  PDUs.  1993 

ITU-TS  X.233  Protocol  for  Providing  Connectionless-Mode  Network  Service  (ISO  8473-1).  Draft.  1993 

ID.  ISDN: 

ISQflEC  9574*  Provision  of  the  OSI  Connection-Mode  Network  Service  (CONS)  by  Packet  Mode  Terminal 

Equipment  Connected  to  »n  Integrated  Services  Digital  Network  (ISDN) 

DAM  1  Provision  of  the  CONS  on  an  ISDN  Circuit-Switch  Channel  Connecting 

Directly  to  the  Remote  Terminal 
CD  11371  Addressing  in  Pr.vste  Integrated  Services  Digital  Network 

CD  11572  Addressing  in  Private  Integrated  Services  Network  -  Circuit  Mode  Bearer  Services  -  Inter-Exchange 

Signalling  Procedures  and  Protocol, 

CD  11373  Synchsoniration  Methods  and  Technical  Requirements  far  Private  Integrated  Services  Networks 

CD  11374  Private  Integrated  Services  Network  -  Qrcuit  Mode  64  kbit/s  Bearer  Services  -  Service  Definition  - 

Functional  Capabilities  and  Information  Flows 

ITU-TS  LI 30  Attributes  for  the  Characterization  of  Teleoommunicatioos  Services  Supported  by  an  ISDN  and 

Network  Capabilities  of  an  ISDN 

ITU-TS  L140  Rev  1  Attribute  Techniques  for  dm  Characterizetioo  of  Teleconunnnication  Services  Supported  by  an  ISDN 
md  Network  Capabilities  of  an  ISDN 
ITU-TS  L141  ISDN  Network  Charging  CqwhiHHss  Attributes 

ITU-TS  1310  Rev  1  ISDN  -  Network  Puoctiomd  Principles 
ITU-TS  1311  Rev  1  B-1SDN  General  Network  Aspects 
ITU-TS  L324  ISDN  Network  Arcbitactura 

ITU-TS  L326  Reference  Configurations  for  Relative  Network  Reeoorce  Requirements 

ITU-TS  L330  ISDN  Numbering  end  Addressing  Principtee 

ITU-TS  L331  Numbering  Plan  for  the  ISDN  Em 

ITU-TS  L332  Numbering  Principles  for  Interworking  Between  ISDNi  and  Dedicated  Networks  with  Different 

Numbering  Plane 

ITU-TS  L334  Principles  Relating  ISDN  Numben/Subaddnsaes  to  the  OSI  Reference  Model  Network  Layer 

ITU-TS  1.335  ISDN  Routing  Prtacipies 

ITU-TS  L330  Rev  1  Geoeral  Aspects  of  Quality  of  Service  and  Network  Performance  in  Digital  Networks,  Including 
ISDNs 

ITU-TS  L351  Rev  1  Recommendations  in  Other  Services  Including  Network  Performance  Objectives  that  Apply  at 
Reference  Point  T  of  an  ISDN 

ITU-TS  L352  Network  Performance  Objectives  for  Connection  Processing  Delays  in  an  ISDN 

ITU-TS  L333  Refarenoe  Eveuta  for  Defining  ISDN  Performance  Panmasare 


Appendix  D 


D-34 

UNCLASSIFIED 


Network  Layer  Standards 


UNCLASSIFIED 


ITU-TS  L354 
ITU-TS  L335 
ITU-TS  L361  Rev  1 
ITU-TS  L362  Rev  1 
ITU-TS  L363  Rev  1 
ITU-TS  L364 
ITU-TS  L370 
ITU-TS  1371 
ITU-TS  L372 
ITU-TS  L373 
ITU-TS  L374 
ITU-TS  L450* 
ITU-TS  L451« 
ITU-TS  L432 

ITU-TS  L453(7>* 
mj-TS  LSOO  Rev  1 
ITU-TS  L501 
ITU-TS  LSlORevl 
ITU-TS  L5U 
ITU-TS  LS1S  Rev  1 
ITU-TS  1.520  Rav  1 
ITU-TS  L523 
ITU-TS  L530  Rev  1 
ITU-TS  L340 

ITU-TS  L350 

ITU-TS  L370 
ITU-TS  L5S0 


Network  fhrihtraiTi  Ohjictirei  for  Parker  Moris  Ob— w leatira  ht  m  BOW 
ISDN  <4  kM*  Coaatctkm  Type  Availability  fmfotmm cm 
B-ISDN  ATM  Layer  Speculation 

B-ISDN  ATM  Adaptation  Layer  ( AAL)  Functional  Description 

B-ISDN  ATM  Adeptetire  Layer  (AAL)  Specification 

Support  of  Broad  Band  Comactiookss  Data  Service  on  B-ISDN 

Congestion  Management  for  the  ISDN  Frame  Relaying  Bern  Service 

Traffic  Control  and  Congestion  Control  in  B-ISDN 

Frame  Relaying  Bearer  Service  Networfc-to-Network  Interface  Requirement! 

Network  Capabilities  to  Support  Univanal  Panooal  Requirement! 

Framework  Rornflurweriitinci  oo  Network  Capabilities  to  Support  Multimadia  Services 

ISDN  Uaar-Natwoik  Interfere — Layer  3  General  Aspects 

ISDN  User-Network  faterfhee— Layer  3  Specification  for  Baric  CaB  Control 

ISDN  Uaar-Natwork  Interface  Layer  3  Specification  Generic  Procedure*  for  the  Control  of  As  ISDN 

Supplementary  Sarvicaa 

ISDN  Uaar-Network  Interface  Protocol  for  Management  General  Aspects  (Q.940) 

General  Structare  of  die  ISDN  Interworking  Recommendations 
Frame  Mode  Bearer  Services  (FMBS)  Interworking 
Definitions  and  General  Principles  for  ISDN  Interworking 
ISDN  to  ISDN  Layer  1  Internetwork  Interfere 
Parameter  Exchange  for  ISDN  Interworking 
General  Arrangement  for  Network  Interworking  Between  ISDNt 

Interworking  Between  ISDN  and  Network*  Which  Operate  at  Bit  Rates  Less  Than  64  kfcit/k 
Network  Interworking  Between  an  ISDN  and  a  Public  Switched  Telephone  Network  (PSTN) 

General  Arrangement  for  Network  Interworking  Between  Orenit  Switched  Public  Date  Networks 
(CSPDNs)  ad  ISDNi  for  the  Prevision  of  Data  Transmission  Sacvires 

General  Arrangement  for  Network  Interworking  Between  Packet  Switched  Public  Data  Networks 
(PSPDNs)  and  ISDNs  far  the  Provision  of  Data  TVansmiasioo  Services 
Public/Private  ISDN  Interworking 

General  Arrangements  for  Interwaddng  Between  B-ISDN  and  64  kbilA  Breed  ISDN 


Note:  Additional  ISDN  ataadreds  are  Haled  in  Section  DC  A  at  the  and  of  tMs  appendix. 


E.  ROUTING  AND  RELAY: 


ISO  9342* 


ISOflEC  TR  9575* 
ISQTBC  10028-1* 


ISOflEC  10028-2* 

ISOAECTR  10029* 
ISOrfEC  10030 


D(S  10090-2 

ISOOBC  10909 

DIS  10747* 

CD  11571 
CD  1 1372 

nu-Tsx.no 

TTU-TSXJ33 


End  System  to  Intermediate  System  Rooting  Exchange  Protocol  for  Use  far  Conjunction  with  the 
tTOfoooi  ror  nuTKang  me  t^ooD©ct»otuc«-M(Xic  neewone  ocrvice 
Cor  1  Technical  Corrigendum  1 

PDAM1  Dynamic  Discovery  of  OSI  Addraeses  by  End  Systems 

OSI  Routing  Framework 

Definition  of  the  Relaying  Functions  of  a  Network  Layer  Intermediate  Syeteu.  Pert  l:  Connection- 
mode  Network  Service,  1993 

PDAM 1  ConoectioBleta-mode  Relaying  Functions 

Definition  of  the  Relaying  Fractions  of  i  Network  Layer  Intermediate  System.  Part  2: 
Connectionless  Network  Service.  1993 
Operation  of  an  X23  Interworking  Unit 

End  System  to  Intermediate  System  Rooting  Information  Exchange  Protocol  for  Uae  in  Conjunction 
with  ISO  8878  (X.2SPLP)[SC6N  5006] 

Cor  l  Technical  Corrigendum  1 

PDAM  1  Dynamic  Discovery  of  OSI  NSAP  Adrheeae*  by  Bnd  Syrtwnr 

AM2  PICS  Proforma 

PDAM3  Specification  of  IS-SNARB  Interactions 

End  System  to  Interaiidiete  System  Rooting  Information  Exchange  Protocol  for  Uae  in  Compaction 
with  ISO  8878  (XJS  PLP),  P*t  2;  PICS  Proforma 

Intermediate  System  to  Intermediate  System  Rooting  Information  Exchange  Protocol  for  Uae  in 
Conjunction  with  ISO  1473 

Protocol  for  Exchange  of  Inter-Domain  Routing  Information  Among  Intermediate  System  to 

Support  Forwarding  of  ISO  8473  PDUt 

Addressing  in  Private  Integrated  Services  Digital  Network 

Addressing  hi  Private  Integrated  Service*  Network  •  Circuit  Mod*  Bearer  Services  •  Inter-Exchange 
Signalling  Procedural  end  Protocol 

International  Rooting  Principles  and  Rooting  Plan  for  Public  Date  Network*.  1988 

Rooting  Principles  for  Interconnecting  the  Mvitime  Satellite  Deta  Trmamtraina  System  With 

Public  Data  Networks.  1988 
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F.  NETWORKING  AND  INTERWORKING: 


rru-rs  X.300 

ITU-TS  X.301  Rev  1 

rru-Ts  X.302 

itu-ts  x.305 

rru-rs  x.310 

itu-ts  x.32o 

ITU-TS  X  .321/1 340 

ITU-TS  X322 

rru-Ts  X. 323 
ITU-TS  X.324 

rru-Ts  X.325 

ITU-TS  X.326 

ITU-TS  X327 

ITU-TS  X340  Rev  I 
ITU-TS  X.350 

rru-Ts  X351 

rru-Ts  X.332 

ITU-TS  X.353 

ITU-TS  X. 370 

rru-Ts  X3n 

ITU-TS  X.610 
ITU-TS  X.612 

ITU-TS  X.613 

ITU-TS  X.614 

ITU-TS  X.615 
ITU-TS  X. 620 
ITU-TS  X.622 

ITU-TS  X.623 


General  Principle*  and  Arrangements  for  Interworking  Between  Public  Data  Networks,  and  Between 
PDNs  and  Other  Public  Networks 

Description  of  the  General  Arrangement  for  Call  Control  Within  a  Subnetwork  and  Between 
Subnetworks  for  the  Provision  of  Data  Transmission 

Description  of  the  General  Arrangement  for  Internal  Network  Utilities  Within  a  Subnetwork  and 
iiiy«M»<ti«to  Utilities  Between  Subnetworks  for  the  Provision  of  Data  Transmission  Services 
Functionalities  of  Subnetworks  Relating  to  the  Support  of  the  OSI  Connection-Mode  Network 
Service 

Procedures  and  Arrangements  for  DTE  Accessing  Circuit  Switched  Digital  Data  Services  Through 
Analogue  Telephone  Networks 

General  Airangements  for  Interworking  Between  ISDN*  for  the  Provision  of  Data  Transmission 
Services 

General  Arrangements  for  Interworking  Between  Circuit  Switched  Public  Data  Networks  (CSPDNs) 
and  ISDNs  for  the  Provision  of  Data  Transmission  Services 

General  Arrangements  for  Interworking  Between  Packet  Switched  Public  Data  Networks  (PSPDNs) 
and  CSPDNs  for  the  Provision  of  Data  Transmission  Services 
General  Arrangements  for  Interworking  Between  PSPDNs 

General  Arrangements  for  Interworking  Between  PSPDNs  and  Public  Mobile  Systems  for  the 
Provision  of  Data  Transmission  Services 

General  Arrangements  for  Interworking  Between  PSPDNs  and  ISDNs  for  the  Provision  of  Data 
Transmission  Services 

General  Arrangement*  for  Interworking  Between  PSPDNs  and  Common  Channel  Signalling 
Network  (CCSN) 

General  Arrangement*  for  Interworking  Between  PSPDNs  and  Private  Data  Networks  for  the 
Provision  of  Data  Transmission  Services 

General  Arrangements  for  Interworking  Between  PSPDNs  and  the  International  Telex  Network 
General  Interworking  Requirements  to  be  Met  for  Data  Transmission  in  International  Public  Mobile 
Satellite  Systems 

Special  Requirements  to  be  Met  for  Packet  Assembly /Disassembly  Facilities  (PAD*)  Located  at  or  in 
Association  with  Coast  Earth  Stations  in  the  Public  Mobile  Satellite  Service 
Interworking  Between  Packet  Switched  Public  Data  Networks  and  Public  Maritime  Mobile  Satellite 
Data  Transmission  Systems 

Routing  Principles  for  Interconnecting  Public  Maritime  Mobile  Satellite  Data  Transmission 
Systems  with  Public  Data  Networks,  1988 

Arrangements  for  the  Transfer  of  Internetwork  Management  Information,  1988 

General  Arrangements  for  Interworking  Between  Frame  Relaying  Public  Data  Network*  and  ISDNs, 

Draft.  1993 

Provision  and  Support  of  the  OSI  Connection-Mode  Network  Service,  1992 

Provision  of  the  OSI  Connection-Mode  Network  Service  by  Packet  Mode  Terminal  Equipment 

Conoectod  to  an  ISDN,  1992 

Use  of  ITU-TS  X.23  Packet  Layer  Protocol  in  Conjunction  with  ITU-TS  X.21/TTiJ-TS  X.21  bis  to 
Provide  the  OSI  Connection-Mode  Network  Service,  1992 

Use  of  ITU-TS  X.2S  Packet  Layer  Protocol  in  Conjunction  with  ITU-TS  X.21/TTU-TS  X.21  bis  to 

Provide  the  OSI  Connection-Mode  Network  Service  over  die  Telephone  Network,  1992 

Provision  of  the  OSI  Connection- Mode  Network  Service  over  Frame  Relay,  1992 

Provision  and  Support  of  the  OSI  Connection- Mode  Network  Service  over  Frame  Relay,  1992 

Use  of  ITU-TS  X.23  Packet  Layer  Protocol  in  Conjunction  with  ITU-TS  X.21/ITU-TS  X.21  bis  to 

Provide  die  OSI  Connection-Mode  Network  Service  over  the  Telephone  Network,  1992 

Use  of  ITU-TS  X.23  Packet  Layer  Protocol  in  Conjunction  with  ITU-TS  X.21TTU-TS  X.21  bis  to 

Provide  the  OSI  Connectioo-Mode  Network  Service  over  the  Telephone  Network.  1992 


G.  AUTOMATIC  CALLING/ANSWERING.  EQUIPMENT: 

ITU-TS  V.25  Automatic  Answering  Equipment  and/or  Parallel  Automatic  Calling  Equipment  on  the  Gene.’*) 

Switched  Telephone  Network  Including  Procedures  for  Disabling  of  Echo  Control  Devices  for  Both 
Manually  and  Automatically  Established  Calls 

ITU-TS  V.25  bis  Automatic  Calling  and/or  Answering  Equipment  on  the  General  Switched  Telephone  Network 
(GSTN)  Using  the  100-Series  Interchange  Circuits 


H.  CIRCUIT  SWITCHED  SERVICE: 

Cowed  by  COTT  X.21,  XJ4,  X.26,  X.27,  ISO  4903,  listed  under  Physical  Layer  Standards 
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UNCLASSIFIED 


Network  Layer  Standards 


■■■  ■  _  =  -  - 


UNCLASSIFIED 


I.  LOCAL  AHA  NETWORKS  (LANs): 

HS1003S*  MAC  SobUyar  latMcosMctioa  (MAC  Bridgte*) 

ISQflBC  10099*  MAC  Same*  Dafiniikn 

OdMr  Modwdi  m  covarod  in  to  diacMtaion  of  LAN  aundank  for  Layar  1  (Sactioa  II) 
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D-37 

UNCLASSIFIED 


Netwcxk  Layer  Standards 


UNCLASSIFIED 


AppewfixD 


D-38 

UNCLASSIFIED 


Netwoik  Layer  Standards 


UNCLASSIFIED 


V.  LAYER  4:  TRANSPORT  LAYER22 

A  Gonoral 

B.  Connocdon-Oriontod  Sorvfco 

C.  Conmctionhw  Service 

OConton  wence  Teetfno 

S  WlPvlfl 

A.  GENERAL) 

STANAG4254*  NATO  Refersace  Model  for  OS!  •  Layer  4  (Transport  Layer)  Service  Definition 

STANA04264*  NATO  Reference  Model  for  OS1  -  Layer  4  (Transport  Layer)  Protocol  Specification 

ISO  M72*  Transport  Service  Definition 

Cor  1  Tedmical  Corrigendum  1 

AD  U  Connectionless  Mode  Truemiaeioa 

ISQAECTR  10023*  A  Formal  Description  of  ISO  8072  in  LOTOS  (swrittag  decision  cooceoiag  talker  progiaseioa) 

POABCTR 10172*  Netwosfc/Transport  Protocol  Interworking  Specification 

PDIR  10734  OnidaHnas  for  Bridged  LAN  Source  Rooting  Operation  by  Bod  Syrian* 

ISQflBCTR 10735  Standard  Oronp  MAC  Addresme 
DIS  10736  Transport  Layer  Security  Protocol 

PDAM 1  Security  Association  Establishment  Protocol 

1SQABC  10737*  Sf — ifleeti - *  *”Tm-r‘-  *1-tiTtTmiml  Tr'nrnieti^n  Related  in  fHT  TYaeapnit  I  ajsi  It  miles  lit 

GKMBC  10740-1  Taxi  aad  Office  Syatana  -  Reforanced  Data  Transfer,  Part  1:  Abatract  Service  mhaiM 

1SQSBC  10740-2  Text  end  Office  Syetetnt  -  Reforanced  Data  Tranafer,  Fait  2:  Protocol  Specification 

ISOflBC  11570*  Transport  Protocol  Identification  Mechanam 

ITU-TS  T.70*  Network-Independent  Basic  Transport  Service  for  the  Telematic  Service* 

■  ITU-TS  7L214  IVneport  Service  Definitioo  of  OSI  for  (XTTT  Application*  (ISO  W72, 1906) 

ITU-TS  X-234  Protocol  for  Providing  foe  OSI  Connectionlaaa-Mode  Transport  Service,  Draft.  1993 

ITU-TS  XJ64  Transport  Protocol  Identification  Mechaobm  (ISO  11570),  Draft,  1993 

ITU-TS  JL274  Transport  Layer  Security  Protocol  (ISO  10736),  Draft,  1993 

ITU-TS  X2S4  Bieeaenti  of  Management  Information  Related  to  foe  OSI  Transport  Layer  (ISO  10737),  Draft.  1993 

■  •  CONNECTION-ORIENTED  SERVICE: 

ISQflECS073*  Conoactiou  Oriented  Transport  Protocol  Specification,  Edition  3 

ISQSBCTR  10024*  AFotmalDeacriptkMofISO8073  inLOTOS 

pDBP  IUSS-1  Common  Upper  Layer  Requirements,  Part  l:  Baaic  Connection  Oriantad  Rsqniremsata 

pPtSP  11ISS-2  Gpmmoo  Upper  Layer  Raqrinmeots,  Part  2:  ROSE  Based  Reqoimmeats 

pDISP  Ultt-3  Common  Upjat  Layer  Requirements.  Part  3:  Mfadmel  OSI  Uppar  Layer  PacgMm 
ITU-TS  3L224  Protocol  for  Providing  fee  OSI  Connection-mode  Ttanaport  Service  (ISO  S073X  1901 

C.  CONNECTIONLESS  SERVICE: 

ISO  S602*  Protocol  for  Providing  foe  Coaaactioalesi  Mod*  Transport  Service 

DAM1  PICS  Proforma 

D.  CONFORMANCE  TESTING: 

ISQflBC  10025-1*  Tranaport  Conformance  Tearing  for  Connection  Oriented  Transport  Protocol  Opamfog  over  foe 
Connection  Oriented  Network  Servioe  (CONS),  Part  1:  Oanarml  Principles 
1SQSBC  10025-2*  Traneport  Conformance  Tearing  for  Connection  Oriented  Transport  Protocol  Operating  over  foe 
Comwcfom  Oriented  Netwotk  data  Transfer,  Parti:  Abatract  Service  DriWtioa 
1SQ0BC  10025-3*  Tranaport  Coofomaaca  Testing  for  Connection  Oriented  Traneport  Protocol  Operating  over  foe 
Connection  Oriented  Network  Service  (CONS),  Pwt  3:  Abstract  Tast  Snita  Spaciflcatioa 
BOflEC  10739-1  Conferment*  Test  Suit*  for  9041  -  Virtual  Terminal  Baric  Claes  Protocol,  Pmtl:  Test  Salt* 
Stortme  and  Tart  Pmpoees 


22  The  symbol  ♦  Is  need  throughout  this  apptadix  to  ktaotify  thorn  standards  iociadad  In  foe  Saptanfotr  1993  NOSIF 
Strmttgy. 
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UNCLASSIFIED 


UNCLASSIFIED 
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D-40 

UNCLASSIFIED 


Transport  Layer  Standards 


UNCLASSIFIED 


VL  LAYERS:  SESSION  LAYER23 


A  General 

B.  Connection-Oriented  Service 

C.  Connection)***  Service 

D.  Telematic  Service* 


A.  GENERAL: 

STAN  AO  4233* 
STAN  AG  4265* 

ISO  8326* 


DIS  8326.2 


ISO  8327* 

EXS  8327-1 

ISO  8327-2* 
ISQ/IEC  TR  9371* 

ISOfiEC  TR  9372* 

EXS  10168-1* 

CD  10168-2* 

CD  10168-3* 

1XS  10168-4* 

SC21  N  6110 
ITU-TS  X415 
ITU-TS  X.223 
ITU-TS  X.245 


NATO  Reference  Model  for  09  -  Layer  3  (Session  Layer)  Service  Definition,  Draft 
NATO  Refeience  Model  for  OSI  •  Layer  3  (Semion  Layer)  Protocol  Specification,  Draft 
Connection  Oriented  Session  Service  Definition  (X.215) 

AM4  Additional  Synchronization  Functionality 

WDAM  3  Removal  of  Session  Layer  Serial  Number  Limitation 
Connection  Oriented  Session  Service  Definition.  Edition  2  (X.215) 

AM  3  Incorporate  Additional  Synchronisation  Functionality 

WDAM  4  Removal  of  Session  Layer  Serial  Number  Limitation. 

Basic  Connection  Oriented  Session  Protocol  Specification.  Revised  BdMon.  1990 

Basic  Connection  Oriented  Session  Protocol  Part  1:  Protocol  Specification,  Edition  2  of  ISO  8327 

(X.223) 

Basic  Connection  Oriented  Session  Protocol  Part  2:  PICS  Proforma  (X.245) 

LOTOS  Description  of  the  Session  Service  (TR  has  been  cancelled  now  that  the  Second  Edition  of 
Session  Service  is  published) 

LOTOS  Description  of  the  Session  Protocol  (TR  has  been  cancelled  now  that  the  Second  Edition  of 
Session  Service  is  published) 

Conformance  Test  Suite  for  the  Session  Protocol  Part  1:  Test  Suite  Structure  and  Test  Putpoees 
Conformance  Test  Suite  liar  the  Session  Protocol  Past  2:  Common  Session  Ababact  Test  Sake 
Conformant*  Test  Suite  far  the  Session  Protocol  Past  3:  Abstract  Test  Suite  for  the  CS  Method 
Conformance  Test  Suite  for  the  Session  Protocol  Part  4:  Session  Test  Management  Protocol 
Specification 

Session  Layer  Extension  to  Support  Re-Use  of  Transport  Connection* 

Session  Service  Definition  for  OSI  for  COTT  Applications  (ISO  8826),  1988 
Session  Protocol  Specification  for  OSI  for  CCTTT  Applications  (ISO  8327),  1988 
Coimnction less- Mode  Session  Protocol  Protocol  Specification  (ISO  9348),  Draft,  1993 


B.  CONNECTION-ORIENTED  SERVICE: 


ISO  8327* 


DIS  8327-1 

ISO  8327-2* 
ITU-TS  XJ25 


Basic  Cormsction-Orientad  Session  Protocol  Specification  (X.223) 

AM  3  Incorporate  Additional  Synchronisation  Functionality 

WDAM4  Removal  of  Semion  Layer  Serial  Number  Limitation, 

Basic  Connection  Oriented  Session  Protocol  Part  1:  Protocol  Specification.  Edition  2  of  ISO  8327 
(X.223) 

Basic  Connection  Oriented  Semion  Protocol  Pari  2:  PICS  Proforma  (X343) 

Session  Protocol  Specification  for  OSI  for  CC1TT  Application  (ISO  8327),  1988 


C.  CONNECTIONLESS  SERVICE: 


ISO  9348* 
ISOflBC  9548-2 

ITU-TS  X-Z35 
rrU-TS  X.255 


Session  Connectionless  Protocol  to  Provide  Connectionless -Mode  Session  Service  (XJ 35) 

Session  Connectionless  Protocol  to  Provide  Connectionless-Mode  Session  Service,  Pest  2:  PICS 
Proforma,  1993  (X.255) 

Connectionless-Mode  Session  Protocol  Protocol  Specification  (ISO  9548),  Draft,  1993 
Connectionless-Mod*  Session  Protocol:  PICS  Proforma  (ISO  9348-2),  Draft  1993 


D.  TELEMATIC  SERVICES: 

ITU-TS  TJ  Osnsral  Aspects  of  Group  4  Facsimile  Apparatus 

23  The  symbol  «  is  used  throng  bout  this  appendix  to  identify  those  standards  included  in  foe  September  1993  NOSIF 
Strmugy. 
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UNCLASSIFIED 


Session  L»yer  Standards 


UNCLASSIFIED 


HU-TSTI3IW1 

rru-TsxjB*i 

nu-isxjotMi 

mi-Tsxjiiovi 


OmMoI  Ptaoadmee  for  Tetalas  and  Group  4  Facsimile  Services 

Pacfeat  AmaahtjdDiaaaesutbijr  Facility  (PAD)  in  a  Public  Data  Network  (PDN) 

.  Interface  IKmn  DIB  Md  DCE  far  Start-Stop  Tranaaisaion  Services  oa  Public  Data  Networks 
DTE/DCE  liMhn  for  a  Start/Stop  Mode  DTE  tba  PAD  in  a  PDN  Situated  in  the  Same 


IIV-TSXJPBmr  I 


Procedures  for  foe  ffirtianfe  of  Cotfmi  Information  and  Uaer  Data  Between  a  PAD  and  a  Packet 
Mode  DTE  or  Another  PAD 


D-42 

UNCLASSIFIED 


Session  Layer  Standards 


UNCLASSIFIED 


m  LAYER  6:  PRESENTATION  LAYER24 


A.  Gwmral 

B.  Conrmcttontooo  Boorica 

C.  AMI tact  Syntax  Notation  On*  (ASN.1) 

D.  Tahmate  Swvteoo 


A.  GENERAL: 


STANAQ4256* 
STANA04266* 
ISO  K22* 


USSS22J 

isotm» 


US  M23-1 
ISCMBC  SS23-2 

ISQAEC  10729-1 
US  10729-2 

WD  10729-3 

SC21N090S 

SC21N7092 

nV-TSX21< 

nU-lSX226 

mi-TSXJM 


Pi— nlstinn  Layer  Service  Definition 
ft— nation  Layer  Protocol  Spedficattoo 
CoHnection-Orieotod  Pwieentatioo  Service  DefioUoe  (X.216) 

AM  1#  ronmctionlw  -Mods  PmestatlM  Swin 

AM  2  IMimiiadUaerData 

DAM  3  Abstract  Syntax  Registration 

AM  4  Support  of  Session  Symsaslric  Synchronisation  Service 

AMS  Delivery  of  Additional  Session  Syncfarooi—  ftnirtionalMy  to  tbs 

Preseotatioa  Service  User 
Basic  ftesentatioo  Service  Definition,  Edition  2 
Connection -Oriented  Presentation  Protocol  Specification  (X226) 

AM  2  Unboiled  User  Data 

DAM  3  Transfer  Syntax  Registration 

AM4  ‘iiffintt  nf  Tallinn  Tpaiaatrir  Synchrouiration  Tirrtm 

AMS  Additional  Synchronization  ftncttonality  to  tbs  ftp— tattoo  Service 

User 

Connection  Oriented  Pra— tattoo  Protocol.  Part  1:  Protocol  Specification.  Edition  2  of  ISO  1823 
Connection -Oriented  Presentation  Protocol  Specification.  Part  2:  Presentation  Protocol 
fiaptomantatinn  Conformance  Statement  (PICS)  ftofoma  (X246) 

Ooi foflMBCi  Tut  Suite  for  ite  Ptuntitiofl  ftotecol,  PM  1:  Tut  Suite  Sttvctev  Md  Tut  PupoM 
Ctmtotm— n  Teet  Snite  far  the  fte—rton  Protocol.  Part  2:  Teat  Sabe  for  ASN.l  Eaoodtogs  aad 
Test  Porpceei  for  Preren ftion  Protocol 

Conformance  Test  Snite  for  the  Press atatica  Layer.  Part  3:  Common  Preemtetine  Abetract  Teet 
Snite 

Reqneet  for  Comments  on  Comprasstoo  in  Presentation  Layer 

Liatoon  Statement  to  SC1S  Concerning  the  Uee  of  Diati^nished  Encoding  Rnlee  to  Doc—  SC21 
N  6476 

Praaantatioo  Service  Definition  tor  OSI  for  CdTT  Appiicattoaa  (ISO  M22X  198S 
ftrnentaticn  Protocol  Spedficattoo  tor  OSI  for  COTT  Application  (ISO  SS23).  19M 
Coonectioo-Mode  Presentation  Protocol:  PICS  Proforma  (ISO  M23-2),  Draft,  1993 


B.  CONNECTIONLESS  SERVICE: 


ISO  1822  AMI* 
1309376* 

DCS  9376-2* 

rru-xsxj36 

TTU-TSXJ56 


Presentation  Conaacttootosa  Protocol  to  Provide  Conaccttonleer  Mode  Pra— tattoo  Sarvice 
(X.236) 

Pra— tattoo  Protocol  to  Provide  the  Conoacttonl—  Mode  fteaantatton  Service.  Part  2:  PICS 
Proforma  for  Co— ctionlaii  Praaeotatioo  Protocol  (X.236) 

Con— tkmlaai  Mode  Pra— tattoo  Protocol  Protocol  Spadflratton  (ISO  9376),  Draft  1993 
Co— ttoaleii  Mode  Pratanhtfinn  Protocol:  PICS  ftofor—  (ISO  9576-2),  Draft  1993 


C.  ABSTRACT  SYNTAX  NOTATION  ONE  (ASN.l): 

STANAG4256*  Spedficattoo  of  ASN.l 

STANA04299*  Spadflcalion  of  Basic  Encoding  Rolaa  for  ASN.l 


24  The  symbol  «  Is  need  throughout  (Ms  qapendix  to  identify  thoaa  rtandarda  toctodad  in  the  Sept— bar  1993  NOSIF 
Strategy. 

Appendix  D 
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UNCLASSIFIED 


UNCLASSIFIED 


DQABC  8824 


ISOAEC  U24-1 


ISOflBC  SS24-2 

ISQflBC  SS24-3 
ISOflBC  SS24-4 

1SOABC  8S25 


DCS  SS25-1 


DCS  W  25-2.2 
DCS  SS25-3 
DCS  SS25-4 
SC21  N  <130 

rru-Tsxjot 

ITU-TS  X.309 
ITU-TS  X.6S0 
rru-Tsx.Mj 
ITU-TS  X. <02 
ITU-TS  X.  M3 
IIV-TSX.<M 
ITU-TS  X.491 
ITU-TS  XOK 


D.  TELEMATIC 

ITU-TS  T.6 
ITU-TS  TJ1 
ITU-TS  TAl  Rev  1 
rrU-TST.73 


Specification  of  Abstract  Syntax  NoUtioa  One  (ASN.l)  (X. 208) 

DAM  2  Amendments  to  ISO  8824  to  Give  ISO  8S24  Part  1:  Specification  of 
Basic  Notation 

WDAM  4  Removal  of  Definition  of  Root  Arcs  of  Object  Identifier  Tree 
Cor  1  Draft  Technical  Corrigendum  l 

Specification  of  Abstract  Syntax  Notation  One  (ASN.l).  Part  1:  Specification  of  Basic  Notation 
(X.6S0) 

PDAM  3.2  Roles  of  Extensibility 

Specification  of  Abstract  Syntax  NoUtioa  One  (ASN.l),  Part  2:  Information  Object  Specification 
<X.««1) 

Specification  of  Abstract  Syntax  Notation  One  (ASN.l),  Part  3:  Constraint  Specification  (X.682) 
Specification  of  Abstract  Syntax  Notation  One  (ASN.l),  Part  4:  Parameterization  of  ASN.l 
Specifications  (X.<S3) 

Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.l)  (X.209) 

DAM  2  Amendments  to  ISO  M25  to  Give  ISO  8S25  Part  1:  Basic  Encoding  Rule* 

AM  3  Rules  for  Extensibility 

Cor  1  Draft  Technical  Corrigendum  1 

Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.l),  Part  1:  Basic 
Encoding  Rules  (BER)  (X.690) 

WDAM  1  Light  Weight  Encoding  Rules  far  ASN.l 
pacification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.l),  Part  2:  Packed 
Bncodfaag  Rules  (PER) 

Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.l),  Part  3: 
Distinguished  md  Canonical  Eaooding  Rules  (X.692) 

Specification  of  Basic  Rules  for  Abstract  Syntax  Notation  One  (ASN.l),  Part  4:  Test  Suits 

Structure  and  Test  Purposes  far  ASN.l  Encodings 

Working  Draft  for  ASN.l  Eacodh*  Rules  to  Provide  Upper  Layer  Security  and  Compression 
Specification  of  Abstract  Syntax  Notation  One  (ASN.l),  19SS  (see  X.680) 

Specification  of  Bmic  Encoding  Rules  far  Abstract  Syntax  Notation  One  (ASN.l),  IMS  (see  X.<90) 

ASN.1:  Specification  of  Basic  Notation,  Basic  ASN.l  (ISO  SS24-1).  Draft,  1993 

ASN.l:  Information  Object  Specification  (ISO  1824-2),  Draft.  1993 

ASN.1:  Constraint  Specification  (ISO  8824-3),  Draft,  1993 

ASN.1:  PsrsmsSsrixtion  of  ASN.l  Specifications  (ISO  SS24-4),  Draft.  1993 

Specification  of  ASN.l  Encoding  Rules:  Bask  Encoding  Rules  (ISO  8*25-1),  Draft.  1993 

Specification  of  ASN.l  Encoding  Rules:  Packet  Encoding  Rules  (BO  8825-1).  Draft,  1993 

Specification  of  ASN.l  Encoding  Rules:  Distinguished  and  Canonical  Encoding  Roles 

(ISO  It 25-3),  Draft.  1993 


SERVICES: 

Facsknils  (FAX)  Coding  Schemes  md  Coding  Cootrol  Functions  for  Group  4  Facsimile  Apparatus 
Coded  Character  Sets  for  Telematic  Services 

Character  Repertoire  and  Coded  CbuacUr  Sate  for  the  International  Te  tetri  Service 
Dnoament  Intsrrhsngi  Protocol  far  the  Telematic  Services 
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UNCLASSIFIED 


Presentation  Layer  Standards 


UNCLASSIFIED 


Vm.  LAYER  7:  APPLICATION  LAYER25 


A  QmniI 

B.  061  Dirnctory 

C.  Opatadng  Syatam  Interface  (P081X) 

OAaao^atton  Control  8arvicn  Barnard  UIC8B 
E.  Commftment,  Concunaney.  and  Recovery  (CCR)  Servtoe  Bernard 
F.  Ratable  Tranafar  (FTT),  Remote  Operariona  (RO).  and  Remote  Prooadum  Cal  (RPC) 

Q.  Maaaaga  Handtog  Syatam  (MHS) 

H.  Maaaaga  OHanlad  Taxi  Interchange  Syatam  (MOTtS) 

I.  Manufacturing  Maaaaga  SpacMcadon  (MylS) 

J.  Ha  Tranafar,  Accaaa  and  Managamant  (FTAM) 

K.  Virtual  Terminal  (VT) 

L.  Tarminal  Management  (TM),  VWual  Dinptay  Terminal  (VDT),  and  X-Wfextowe 

M.  Job  Tranafar  and  Manipulation  (JTM) 

N.  Tata  malic  Sarvicaa 

O.  Information  Raaouroa  Dictionary  Syatam  (1RDS) 

P.  Ramota  Darabaaa  Accaaa  (RDA) 

Q.  Date  Management  Concapta 

R.  Databaaa  Languagaa  and  Concapta  (SQL,  NOL) 

S.  Dtatributad  Tranaaction  Procaaalng  (TP) 

T.  Opan  Dtatributad  Procaaalng  (OOP) 

U.  Graphical  Kama!  Syatam  (GKS) 

V.  Programmer's  UtamroMcat  Interactive  Graphica  Syatam  (PHIGS) 

W.  Dialogue  with  Graphicai  Davicaa  (CGI) 

X  Documant  Exchanga  (OOA  ODtF.  DQAM,  DPR.  DTAM) 

Y.  Ptetura  Qaacrlptton  btiotmation  Exchange  (COM,  Data  Compraaaton) 

Z.  Standard  Ganaralzad  Maricup  Languaga  (SGML) 

AA.  Other  AppNcation  Layer  Standards 


A.  GENERAL: 


ISOriBC  9345* 
X9CMBC  10745 
Sai  N  <017 
SC21  N  6797 
SC21  N  6967 
SC21  N  <970 


Application  Layer  Stmctnra  (ALSX1993  (iactadM  XALS)  (XJ07) 

Upper  Layer  Saearity  Modal 

CoaMtaati  on  Standardiiatinn  of  Appbcattoa  hugnaaalc  (do)  htefacaa 
Comawotr  oa  SC21  N  <061,  ModriHag  Recovery  ia  tha  Application  Lay* 

‘Modelling  Recomry  ia  tha  Application  Layor 

Call  far  Co— ante  oa  tha  ftogreerioa  of  tha  ALS  Bataaatoa  to  Cover  Coaaaotioalaaa  Modi  of 


SC21N0971 
901  N  7209 

9Q1N7902 
9C21  N 1019 

9C21NS330 
901  N  S410 
rrU-T5XJ07 


Application  of  XALS  Coaoapta  to  Specification  of  Uqpptegi 

Initial  SOI  Cooiidantioaa  ia  Support  of  the  laitiadoo  of  a  Stady  Period  oa  Application 
Prognuaauric  Iatatfaoaa 

Msmoaoiosy  no  vjhwibdm  nr  ns  usvno|msi  or  Appocstmi  Lijsr  Ssrarai 

Liaiaoa  9tatanaot  to  1TU-TS/S07  oa  QU67  -  OaaaraUatioa  of  A90  Concept,  9O1/W01.  Aagart 

1993 

Ventoo  V2  of  the  APA-Application  Staadvd,  BCMA/TC-TQ9,  Ho—  1993 
Mothodology  «ad  GnirtaHaae  for  As  Dcvclnpaaat  of  Application  Layor  Protooola 
Application  Layer  Sknctan  (ISO  9545),  Draft,  1993 


B.  OBI  DIRECTORY: 

DQABC9994-U  Tha  Phoototy,  Pat  1:  Overview  of  CoacapU,  Modaia  —  Sarvicaa  (XJOO) 

AM  U  Rapticatioo.  Schaaaa  and  Accaaa  Control 

WD9J94-WWDAMi  Aawndnaaata  to  Pam  1  to  9  on  la— aHoaaHwtioa  of  Go  Dbnctary  Bahanwant  of  Ptraamy 


2*  Tha  ayhol  •  ia 
StrtUgy. 

AppdttBxD 


appondfai  to  identify  thoae  ataodards  inctadad  in  *i  Sap— bar  1993  NOSIP 

0-45  Application  Layer  Sfc*JanS* 

UNCLASSIFIED 


UNCLASSIFIED 


WD  9994-1/9  WDAMa  An*w>  to  Path  I  to  9  on  Enhaoremaat  of  Directory  Operational  Security 

WD 9994-1/9  WDAMa  AandMM  to  Part*  Ito  9  on  Directory  Schama  Migration 

DIS  9594-1.2  1b  Dfcmwy.  Pm  1:  Overviaw  of  Concept*.  Modal*  and  Service*.  Edition  2  (XJOO) 

BOflEC  9994-2*  Th* Dhectory, Pert 2:  Model*  (XJ01) 

AMI*  Acoeaa  Control 

AM  2  Schema  Extaasioas 

AM3  Replication 

Gar  1-2  Technical  Corrigenda  1-2 

DB  9594-2J  The  Dhectory.  Part  2:  Modah,  Edition  2  (XJ01) 

BOSK  9994-3#  The  Ohactnry.  Part  3:  Abatract  Service  Definition  (X.511) 

AM  1*  Accea*  Control 

AM2  Replication,  Scheme  md  Enhanced  Searoh 

Cor  1-4  Technical  Corrigenda  1-4 

BO  9994-3.2  7k*  Dhectory.  Part  3:  Abahrsct  Service  Deftakioa,  Edition  2  (X.511) 

ISO/PC  9994  4*  The  Directory,  Port  4:  Pnmdm  for  Diatriboted  Operation*  (XJ18) 

AMI*  Accm  Control 

AM2  Replication.  Schama  Ml  Bah— cad  Search 

Cor  1-3  Technical  Corrigenda  1-3 

ISO  9994-4J  Th*  Oiaaclarjr,  Part  4:  Ptocadmai  for  Diatribntod  Operation*.  Edition  2  QL31S) 

BOMBC  9994-S*  Tka  Dhectory.  Part  5:  Protocol  Spcciflcction*  (XJ19) 

AM  1#  fcsplfcratton 

Cor  1  Technical  Cotrigenrtnm  1 

DO  9994-3 J  Tka  Dhaclcry,  Part  3:  Protocol  Specification!.  Edition  2  0C519) 

DOIBC  9594-4*  Tka  Dhactory.  Part  4:  Sohrted  Attribute  Type*  (X320) 

AM  1*  Iriam  Bxtaurhim 

DO  9394-44  The  Directory,  Part  4:  Selected  Attribute  Type*.  Edition  2  (X.520) 

DQflBC  9994-7*  Tka  Directory.  Part  7:  Selected  Object  CSaaaaa  (X.521) 

AM  1*  Schama  Extanttom 

Cor  1-2  Technical  Cotrigand*  1-2 

BO  9394-7.2  Tka  Directory.  Pert  7:  Selected  Object  Claaaat.  Bdhhn  2  (XJ21) 

DOIBC  9994-S*  Tka  Directory.  Part  I:  Authentication  Piamewotfc  (X.309) 

AMI*  Accent  Control 

1DAM  Security  Enhancement  to  Ptmctoay 

Cor  1  Technical  Corrigandnm  1 

DO  99944L2  Tka  Directory.  Part  I:  Aethenticetion  Framework.  BdUon  2  (X.509) 

DOIBC  9994-9  The  Dhactory.  Part  9:  Rapticatioo  (XJ2S) 

CD  9394-10*  The  Directory,  Part  10:  Directory  PICS  Proiarma  DUA  PICS  Profctme  (XJtl) 

WD  9994-11  Tka  Dhactory,  Part  11:  Directory  PICS  Profiocau  DSA  PfCS  Proforma  (X4S2) 

WD9994  ai  Tka  Dhactory.  Part  w.  Uaa  of  Syatama  Mmagamint  for  Administration  of  Directory 

OOP  10415-1*  BPa  AH  an  -  OSI  Directory.  Part  1:  AIM  11,  DUA  Sapport  of  Directory  Acc***,  January  1993 

OOP  10615-2*  DPI  AU  an -OS  Directory,  Part  2:  ADi  12,  DSA  Support  of  Directory  Aoces*.  January  1993 

nsp  10415-3*  DPB  An  an  -  OSI  Directory,  Part  3:  ADI  21.  DSA  Reepondar  Sola.  My  1993 

IXSP  10615-4*  Dh  An  an -OSI  Directory.  Pert  4:  AH  22.  DSA  Initiator  Role,  Jaiy  1993 

pOSP  10615-3  BPb  An  an -OSI  Directory.  Fart 3:  AIM  31,  DUA  Support  of  Dtaribrted  Operations  1993 

pnsr  10613-4  DPt  An  an  -  OSI  Directory,  Part  6:  ADt  32,  DSA  Support  of  Dfctribmad  Operation*.  1993 

pDISP  10419-7  ISPa  Anna -OSI  Directory.  Part 7:  AIM  41.  Strong  Authentication,  1993 
SC21N4S21  ImtiaartnaiHiitinn  of  the  Directory 

SC21N6S22  UK laapoaae  to N 4011, Call  Dor  Contribution* on  Directory  Eahaacamanta 

SC21N4S42  US  Conoatm  Regarding  the  Ballot  Btaponaee  on  dm  AmhauHraHnn  Sarrica  HP  and  Enhanramantr 

to  Dhactory  Aatfaanticatioa  NP 

SC21N4S72  Llaiaon  St  atamtnt  to  CCITTQ2(yvn  and  SC21/WQ4  from  SCI  Son  MHS  Uaa  of  Dhectory 

SC21  N4973  Head  far  Pmriiaru  to  Coorxiinata  the  Definition  and  Extanalon  of  Directory  Object* 

8C21  N  701S  Uaa  of  Syatfi  Unymant  fcr  k  ikahtiitierton  of  toe  Dhectory 

SC21  N  7000  Bahanoamam  of  Dhectory  Operational  Socorhy 

SC21  N  7001  Ragiatratioa  of  Qnaatkm  Q4/4  on  Directory  Schema  Migration.  Including  Diapoehioa  of 

SCSI  N  7004  Kaqaaat  for  Contribution*  on  Uaa  of  Syatama  Mmagamant  for  Admhriatration  of  the  Ditactoty 

SC21 N  7029  kaquact  lor  Contribution*  on  Movement  of  Dhectory  Information  by  Mean*  Other  Than  Dhectory 

Protocol* 

SC21  N  7004  RaQnart  for  Comamnt*  on  the  Need  for  an  Retention  to  the  Directory  Standard  to  Support  Extended 

Kaiatinmhipa  Among  Dhectory  Eatrie* 

SC21 N702S  Stmm  of  Dhectory  Defect* 

SC21  N  7102  Bxtmaiima  to  ISOflBC  99944  (Certificate  Daflnitiona) 
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SCSI  N  7116 
3C21N7566 
SC21  N  7930 
9C21  N  7931 
SOI  N  7932 
SC21N8315 

SC21/WG4  N  1S27 
ITU-TS  X.500 
ITU-TS  XJ01 

rru-Tsxjw 

ITU-TS  XJ10 
rru-TsxJii 
rru-Tsxjis 
rru-Tsx.519 
rrUTSXL520 
ITU-TS  XJ21 
ITU-TS  X.525 
ITU-TS  XJ81 
ITU-TS  XJ82 


Vakk|  PobuI  on  Cnmploi  Attribute  Tjrpm 
Directory  Inqdemeutor’e  Odd*,  Vwstoa  7 

Working  Document  on  Urn  of  OS!  Syetem  MmagemetU  far  the  Administration  of  the  Directory 
Working  Document  on  the  Intetnatkxulizadoa  of  the  Directory 
Tnh— rwnint  of  Directory  Operational  Security 

Qoettion  oo  Registration  of  Names  of  International  Organisations  for  Directory,  USA,  October 
1993 

Cloeiof  WG4  Plenary  Report  on  Directory  Meeting.  Ottawa 

The  Directory:  Overview  of  CoocepU,  Model*,  and  Service*  (ISO  9594- IX  1988 

The  Directory:  Model*  (IS09594-2X  1988 

The  Directory:  Authentication  Frame  wort  (ISO  9S94-8X  1988 

Overview  of  Sub-eerie*  TJ10  Recommendation* 

The  Directory:  Abctnct  Service  Definition  (ISO  9594-3  X  1988 

The  Directory:  Procedure*  for  Distributed  Operation  (ISO  9594-4X  1988 

The  Directory:  Protocol  Specification*  (IS09594-3X  1988 

The  Directory:  Selected  Attribute  Type*  (ISO  9594-6),  1988 

The  Directory:  Selected  Object  Oa*»e*  (ISO  9594-7),  1988 

The  Directory:  Replication  (ISO  9594-9) 

The  Directory :  DU  A  PICS  Proforma  (ISO  9594-10) 

The  Directory:  DS A  PICS  Proforma  (ISO  9594-10) 


C.  OPERATING  SYSTEM  INTERFACE: 

ISO  2375  Data  Processing  -  Procedure*  for  the  Registration  of  Escape  Sequence* 

ISO  9945-1  Portable  Operating  System  Interface  for  Computer  Environments  (POSIXX  Part  1:  System  Interface 

CD  9945-1.1  Portable  Operating  System  Interface  for  Computer  Environment*  (POSIXX  Part  1-1:  Language 

CD  9945-1.2  Portable  Operating  System  Interface  for  Computer  Environment*  (POSIXX  PM  1.2:  Real-lime  and 

Extensions 

CD  9945-13  Portable  Operating  System  Interface  for  Computer  Environment*  (POSIXX  PM  13:  Distribution 

Services 

CD  9945-13.1  Portable  Operating  System  Interface  far  Computer  Environment*  (POSIXX  PM  13.1:  Tramparant 

File  Access 

CD  9945-133  Portable  Operating  System  Interface  for  Computer  Environment*  (POSIXX  PM  133:  Remote 
Procedure  Call 

CD  9945-133  Portable  Operating  System  Interface  far  Computer  Environmanta  (POSIXX  PM  133:  Transport 
Interface 

CD  9945-13.4  Portable  Operating  System  Interface  for  Computer  Environment*  (POSIXX  PM  13.4:  Name 
Space/Direclory  Services 

DIS  9945-2.1  Portable  Operating  System  Interface  for  Computer  Environment*  (POSIXX  PM  2.1:  Shell  and 

Utilities 

CD  9945-23  Portable  Operating  System  Interface  for  Computer  Environments  (POSIXX  PM  2.2:  User 

Portability  Extensions 

CD  9945-3  Portable  Operating  System  Interface  for  Computer  Environments  (POSIXX  PM  1:  System 

Management 

CD  9945-3.1  Portable  Operating  System  Interface  for  Computer  Environments  (POSIXX  Part  3.1:  General 

Services 

CD  9945-33  Portable  Operating  System  Interface  for  Computer  Environments  (POSIXX  PM  33:  Batch 

Services 

SC21  N  6403  Proposal  for  a  New  Work  Item:  Generic  Operating  System  Interface 


D.  ASSOCIATION  CONTROL  SERVICE  ELEMENT  (ACSE): 

ISO  8649: 1988*  Service  Definition  for  the  ACSE  (X317) 

ISO  8649:1992  Service  Definition  for  the  ACSE,  Revised  Edition  (X.217) 

DAM  3*  Application  Context  Management  Sarvice 
WDAM4  Extensions  to  Support  the  Extended  Application  Layer  Structure 

DIS  86493*  Service  Definition  for  the  Association  Control  Service  Element  (ACSBX  Edition  2 

ISO  8650:1988*  Protocol  Specification  for  the  ACSE  (X.227) 

BO  8650:1992  Protocol  Specification  for  the  ACSE,  Revised  Edition  (X327) 

DAM  2*  Application  Context  Negotiation  During  Asaoderton  Eetahllrhment 
WDAM  3  Application  Context  Management  Service 

WDAM4  Extensions  to  Support  foe  Extended  AppHratiou  Layer  Slructon 
Cor  2  Technical  Corrigendum  2 
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DIS  8650-1 
ISO  86SO-2* 

ISO  10035* 

IMS  10035-2 

ISOflEC  10169-1* 
WD  10169-2 
SC21  N6796 
SC21N6798 
SC21  N  7014 
SC21  N  7092 
ITU-TS  X.217 
ITU-TS  X.227 
rru-Tsx.237 

ITU-TS  X.247 

ITU-TS  X.  257 


Protocol  Specificatioa  for  die  Association  Control  Service  Element  (ACSE),  Edition  2  of  ISO  8650 
Protocol  Specification  for  the  (ACSE)  Part  2:  PICS  Proforma  (X.247) 

Connectionless  ACSE  Protocol  Specification  (X.237) 

WDAM 1  Extensions  to  Support  tbe  Extended  Application  Layer  Structure 
Connectionless  ACSE  Protocol  Specification,  Part  2:  PICS  Proforma  for  Connectionless  ACSE 
Protocol 

Conformance  Test  Suite  for  the  ACSE  Protocol,  Part  1:  Test  Suite  Structure  and  Test  Purposes 

Conformance  Test  Suite  for  the  Session  Protocol,  Part  2:  Common  ACSE  Abstract  Test  Suite 

US  Response  on  Application  Context  Negotiation 

US  Request  for  Extensions  to  ACSE 

ACSE  Enhancements  Covering  ASOs  and  A  SO-  associations 

Proposed  New  Question  Ql/67  on  Generalization  of  ASO  Concept s 

Service  Definition  for  tbe  Association  Control  Service  Element  (ISO  8649),  1992 

Protocol  Specification  for  tbe  Association  Control  Service  Element  (ISO  8650),  1992 

Connectionless-Mode  Protocol  Specification  for  tbe  Association  Control  Service  Element 

(ISO  10035),  1992 

Connection-Mode  Protocol  Specification  for  tbe  Association  Control  Service  Element:  PICS 
Proforma  (ISO  8650-2),  Draft,  1993 

Connectionless-Mode  ACSE  Protocol:  PICS  Proforma  (ISO  10035-2),  Draft,  1993 


B.  COMMITMENT,  CONCURRENCY,  AND  RECOVERY  (CCR)  SERVICE  ELEMENT: 

ISOflEC  9804*  Service  Definition  for  tbe  Commitment,  Concurrency,  and  Recovery  (CCR)  Service  Element 

(X.851) 

PDAM  1.2  Enhancements 

AM  2  Session  Mapping  Changes  (Additional  Resynchronization  Functionality) 

WDAM  3  Restart 

Cor  1  Technical  Corrigendum  1 

IMS  9804.2  Service  Definition  for  the  Commitment,  Concurrency,  and  Recovery  (CCR)  Service  Element, 

Edition  2,  (X.851) 

ISOflEC  9805*  Protocol  Specification  for  the  Commitment,  Concurrency,  and  Recovery  (CCR)  Service  Element 

Protocol  (X.852) 

PDAM  1.2  Enhancements 

AM  2  Session  Mapping  Changes  (Additional  Resynchronization  Functionality) 

WDAM  3  Restart 

Cor  1-2  Technical  Corrigenda  1-2 

ISOflEC  9805-1:1993  Protocol  Specification  for  the  Commitment,  Concurrency,  and  Recovery  (CCR)  Service  Element 
Protocol.  Edition  2  of  ISOflEC  9805,  1993  (X.852) 

IMS  9805-2.2*  Protocol  Specification  for  the  Commitment,  Concurrency,  and  Recovery  (CCR)  Protocol,  Part  2: 

PICS  Proforma  (X .853) 

PDTR  11589  LOTOS  Description  of  the  CCR  Service,  1993 

PDTR  11590  LOTOS  Description  of  the  CCR  Protocol  1993 

SC21N7335  Working  Draft  for  LOTOS  Description  of  the  CCR  Protocol 

SC21N7336  Working  Draft  for  LOTOS  Description  of  the  CCR  Service 

ITU-TS  X.851  Service  Definition  of  CCR  Service  Element,  Edition  2  (ISO  9804),  Draft.  1993 

ITU-TS  X.852  CCR  Service  Element:  Protocol  Specification  (ISO  9805-1),  Draft,  1993 

ITU-TS  X. 853  CCR  Service  Element:  PICS  Proforma,  Edition  2  (ISO  9805-2),  Drift,  1993 


F.  RELIABLE  TRANSFER  (RT),  REMOTE  OPERATIONS  (RO),  AND  REMOTE 
PROCEDURE  CALL  (RPC): 

ISOflBC  9066-1*  Reliable  Transfer  (RT).  Part  1:  Model,  Notation  and  Srrvice  Definition 

ISOflBC  9066-2*  Reliable  Transfer  (RT),  Part  2:  Protocol  Specification 

Cor  1  Technical  Corrigendum  1 

MS  9066-3  Reliable  Transfer  (RT),  Part  3:  PICS  Proforma 

ISO  9072-1:1989*  Remote  Operations  (RO),  Part  1:  Model  Notation  and  Service  Definition,  Edition  2 

PDAM  1  Enhancements  to  Service  Definition 

ISOflBC  9072-1:1993*  Remote  Operations  (RO).  Part  1:  Concepts,  Model  and  Notation,  Edition  3  (aee  IMS  13712-2) 

PDAM  1  Built-In  Operations 

ISO  9072-2.1989*  Ramote  Operations  (RO),  Part  2:  Protocol  Specificatioa,  Edition  2 

PDAM  1  Enhancements  to  Protocol  Specificatioa 

ISQflBC  9072-2:1993*  Ramote  Operations  (RO),  Part  2:  Service  Definition,  Edition  3  (aee  DIS  13712-2) 

PDAM  1  Mapping  to  A-UNTTDATA  and  Built-In  Operations 
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ISOABC  9072-3:1993  XMtoto  Operations  (RO),  Part  3:  Protocol  Specification 

PDAM 1  Mapping  to  A-UNITDATA  ml  Built-In  Operations 
US  9072-4  Remote  Operation  (RO),  Part  4:  PICS  Proforma 

WD  101483  Bade  Remote  Procedure  Call  (RPC)  Uring  OSI  Remote  Operations 

pDISP  11188-1  ISPs  -  Common  Upper  Layer  Requirements,  Part  1:  Basic  Connection  Oriented  Requirements.  1993 

pDISP  11188-2  ISPs  -  Common  Upper  Layer  Requirements,  Part  2:  ROSE  Baaed  Requirements,  1993 

pDISP  11188-3  ISPs  -  Common  Upper  Layer  Requirements.  Part  3:  Minimal  09  Upper  Layer  Facilities,  Inly  1993 

IMS  11578-1*  Remote  Procedure  Call  (RPC).  Part  1:  Model 

DIS  11578-2*  Remote  Procedure  Call  (RPC),  Part  2:  Interface  Definition  Notation 

IMS  11578-3*  Remote  Procedure  Call  (RPC),  Part  3:  Service  Definition 

IMS  11378-4*  Remote  Procedure  Call  (RPC),  Part  4:  Protocol  Specification 

WD  11578-5  Remote  Procedure  Call  (RPC),  Part  S:  PICS  Proforma 

DIS  13712-1  Remote  Operations  (RO).  Part  1:  Model,  1993  (X.880) 

PDAM  1  Built-In  Operations,  January  1994 
DIS  13712-2  Remote  Operations  (RO).  Part  2:  Service,  1993  (X.881) 

PDAM  1  Mapping  to  A-UNITDATA  and  Built-In  Operations,  January  1994 
DIS  13712-3  Remote  Operations  (RO),  Part  3:  Protocol,  1993  (X. 882) 

PDAM  1  Mapping  to  A-UNITDATA  and  Built-In  Operations.  Jammy  1994 
IMS  13712-4  Remote  Operations  (RO).  Part  4:  PICS  Proforma,  1993  (X.883)) 

WD  13712-3  Remote  Operations  (RO).  Part  3:  Enhancements,  1993 

SC21  N  5593  The  Role  of  the  Extended  Application  Layer  Structure  in  the  Standanlixatinn  of  RPC,  ECMA 

SC21  N  3817  Binding  Concepts  Within  RPC.  ECMA 

SC21  N  3819  Modelling  Rationale  for  OSI  RPC,  ECMA 

SC21  N  6638  Issues  for  National  Body  and  Liaison  Organization  Comment  on  RPC 

SC21  N  6719  Recommendations  of  the  CCITT  and  ISO  Collaborative  Interim  Meeting  Covering  ROSE 

Enhancements 

SC21  N  6722  Issues  Concerning  Mapping  of  ROSE  APDUs  onto  A-UNIT-DATA 

SC21  N  6723  Enhancement  to  ROSE,  Part  3:  Concepts,  Model  and  Notation 

SC21  N  6724  Enhancement  to  ROSE,  Part  1:  Service  Definition 

SC21  N  6723  Enhancement  to  ROSE,  Protocol  Definition 

SC21  N  6880  Liaison  Statement  to  CCITT  Q19/V1I  and  SC21/WG6  from  SC18  on  Reliable  Transfer  Service 

Element  (RISE) 

SC21  N  6904  Liaison  Statement  to  SC21  on  Mapping  of  ROSE  APDUs  onto  the  A-UNIT-DATA  Service 

SC21  N  7011  Liaison  Statement  to  SC18  on  Compatibility  of  ROSE  and  RPC  SC21/WG6 

SC21  N  7013  Enhancement  to  ROSE  Concepts,  Model  and  Notation,  ROSE  Service  Definition  and  Protocol 

Specification 

SC21  N  8270  Liaison  Statement  to  SC 21  WG/8  on  the  ROSE  Standard.  ITU-TS  SG7,  October  1993 

ITU-TS  X.218  Rev  1  Reliable  Transfer  Model  and  Service  Definition  (ISO  9066-1),  1993 

ITU-TS  X.219  Remote  Operations:  Model,  Notation  and  Service  Definition  (ISO  9072-1),  1988  (see  X.880, 

X.881) 

ITU-TS  X. 228  Reliable  Transfer  Protocol  Specification  (ISO  9066-2),  1988 

ITU-TS  X.229  Remote  Operations:  Protocol  Specification  (ISO  9072-2),  1988  (see  X  J82) 

ITU-TS  X.248  Reliable  Transfer  Service  Element  -  PICS  Proforma,  1992 

ITU-TS  X.249  Remote  Operations  Service  Element  -  PICS  Proforma,  1992  (see  X.883) 

ITU-TS  X.880  Remote  Operations  (RO),  Part  I  :  Model  1993  (CD  13712-1).  Draft.  1993 

ITU-TS  X.881  Remote  Operations  (RO),  Part  2:  Service,  1993  (CD  13712-2).  Draft,  1993 

ITU-TS  X.882  Remote  Operations  (RO),  Part  3:  Protocol  1993  (CD  13712-3),  Draft,  1993 

ITU-TS  X.883  Remote  Operations  (RO),  Part  4:  PICS  Proforma,  1993  (CD  13712-4X  Draft,  1993 

G.  MESSAGE  HANDLING  SYSTEM  (MHS): 

STAN  AO  4406*  Military  Message  Handling  System,  Draft.  NATO  UNCLASSIFIED  (cf.  ISO  10021, 10611) 

Main  Body,  Draft 

Annex  A — MMHS  Extensions  to  ISO  10021  Series,  Draft 
Annex  B— Security  Aspects  of  MMHS  (under  development) 

Annex  C — Alpha  Profile  Set  (a  delta  specification  to  EWOS  profiles):  AMHlx(M)  on 
Common  Facilities  and  AMH9x(M)  on  Military  Messaging.  Draft 
Annex  D — Alpha/ ACP  127  Gateway  (under  development) 

Annex  E — Alpha/MMHS(84)  Gateway  (under  development) 

Annex  F — Alpha/MHS(88)  Gateway  (under  development) 

Annex  G — Bela  Profile  Set  (under  development) 

Annex  H — Beta/ ACP  127  Gateway  (under  development) 

Annex  I— Beta/Alpha  Gateway  (under  development) 
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DISP  10611-1*  ISPs  AMHln  •  Message  Handling  Systems  -  Common  Messaging,  Part  1:  Service  Support,  1993 

DISP  10611-2*  ISPs  AMHln  •  Message  Handling  Systems  -  Common  Messaging,  Part  2:  Specification  of  ROSE, 

RTSE,  ACSE,  Presentation,  and  Session  for  Use  by  MHS,  1993 
DISP  10611-3*  ISPs  AMHln  •  Message  Handling  Systems  -  Common  Messaging,  Part  3:  AMH11:  Mesaage 
Transfer  (PI),  1993 

rasp  10611-4*  ISPs  AMHln  •  Message  Handling  Systems  -  Common  Messaging,  Part  4:  AMH12:  MTS  Access 
(P2).  1993 

DISP  10611-5*  ISPs  AMHln  -  Message  Handling  Systems  -  Common  Messaging,  Parat  5:  AMH13:  MS  Access 
(P7),  1993 

pDISP  12062-1  International  Standardized  Profiles  AMH  nn  •  Message  Handling  Systems  -  Interpersonal 
Messaging,  Part  1:  IPM  MHS  Service  Support,  August  1993  (review  ended  December  1993) 
pIHSP  12062-2  International  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems  -  Interpersonal 
Managing,  Part  2:  AMH  21,  IPM  Content,  August  1993  (review  ended  December  1993) 
pDISP  12062-3  International  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems  -  Interpersonal 
Mttraging,  Part  3:  AMH  22,  IPM  Requirements  for  Message  Transfer  (PI),  August  1993  (review 
ended  December  1993) 

pIHSP  12062-4  International  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems  -  Interpersonal 
Messaging,  Part  4:  AMH  23,  IPM  Requirements  for  MTS  Access  (P3),  August  1993  (review  ended 
December  1993) 

pDISP  12062-5  International  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems  -  Interpersonal 
Messaging,  Part  5:  IPM  Requirements  for  Enhanced  MS  Access  (P7),  August  1993  (review  ended 
December  1993) 

pIHSP  12063  International  Standardized  Profiles  AMH  3  •  Message  Handling  Systems,  1993 

ITU-TS  F.400  Message  Handling  System  and  Service  Overview 

1TU-TS  F.401  Naming  and  Addressing  for  Public  Message  Handling  Services 

ITU-TS  F410  The  Public  Messaging  Transfer  Service 

ITU-TS  F.415  Intercommunication  with  Public  Physical  Delivery  Services 

ITU-TS  F.420  The  Public  Interpersonal  Messaging  (IPM)  Service 

ITU-TS  F421  Intercommunication  Between  the  IPM  Service  and  the  Telex  Service 

ITU-TS  F.422  inamnwimimiMtinn  Between  the  IPM  Service  and  the  Teletex  Service 

ITU-TS  F.435  Message  Handling:  EDI  Messaging  Service 

ITU-TS  F.500  International  Public  Directory  Services 

ITU-TS  X400/F.400  Rev  1  Message  Handling  Systems  (MHSs):  Message  Handling  System  and  Service  Overview 
(ISO  10021-1).  1993  (approval  target  for  common  text  with  ISO/IEC  November  1994) 
rrU-TS  X.401  MHSs  -  Basic  Service  Element!  and  Optimal  User  Facilities,  1984  (discontinued) 

ITU-TS  X4Q2  MHSs  -  Overall  Architecture  (ISO  10021-2),  1992  (approval  target  for  common  text  with  ISO/IEC 

November  1994) 

ITU-TS  X.409  MHSs  -  Conformance  Testing,  1988 

ITU-TS  X.407  MHSs  -  Abstract  Service  Definition  Conventions  (ISO  10021-3).  1988  (approval  target  for  revision 

and  common  text  with  ISO/IEC  November  1994) 

ITU-TS  X.408  MHSs  -  Encoded  Information-Type  Conversion  Rules,  1988 

ITU-TS  X.409  MHSs  •  Presentation  Transfer  Syntax  and  Notation,  1984  [replaced  by  ITU-TS  X.208  (ISO  8824 

with  DAD  1)  and  ITU-TS  X.208  (ISO  8825  with  DAD  1)]  (discontinued) 

ITU-TS  X.410  MHSs  -  Remote  Operations  and  Reliable  Transfer  Server,  1984  (replaced  by  ITU-TS  X.218  (ISO 

9066-1).  ITU-TS  X.219  (ISO  9072-1),  ITU-TS  X.228  (ISO  9066-2),  and  ITU-TS  X.229  (ISO  9072- 
2)]  (discontinued) 

ITU-TS  X.41I  MHSs  -  Menage  Transfer  System:  Absrtract  Service  Definition  and  Procedures  (ISO  10021-4).  1992 

(approval  target  for  common  text  with  ISO/IEC  November  1994) 

ITU-TS  X.413  MHSs  •  Message  Store:  Abstract  Service  Definition  (ISO  10021-5),  1992  (approval  target  for 

common  text  with  ISO/IEC  November  1994) 

ITU-TS  X.419  MHSs  -  Protocol  Specifications  (ISO  10021-6),  1992  (approval  target  for  common  text  with 

ISO/IEC  November  1994) 

ITU-TS  X.420  MHS*  •  Interpersonal  Messaging  Sysem  (ISO  10021-7),  1992  (approval  target  for  common  text 

with  ISO/IEC  November  1994) 

ITU-TS  X.421  COMP  AX  Use  of  MHS,  Draft,  1993  (approval  target  February  1994) 

ITU-TS  X.435  Mesaage  Handling  Systems:  Electronic  Data  Interchange  (EDI)  Messaging  System,  1991  (fast-track 

balloting  in  ISO/IEC) 

nU-TS  X.440  Message  Handling  Systems:  Voice  Messaging  System,  1992 

ITU-TS  X.480  Message  Handling  Systems  and  Directory  Services  Conformance  Testing,  1992 

ITU-TS  X.481  MHSs  •  P2  Protocol:  PICS  Proforma,  1992 

ITU-TS  X.482  MHSs  -  PI  Protocol:  PICS  Proforma,  1992 

ITU-TS  X.483  MHSs  F3  Protocol:  PICS  Proforma,  1992 

ITU-TS  X.484  MHSs  •  P7  Protocol:  PICS  Proforma,  1992 

ITU-TS  X. 485  MHSs  -  Voice  Messaging  System  PICS  Proforma,  1992 
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ITU-lSXAace  Information  Technology  -  Communicatioo  •  Massage  Handling  System  (MHS):  Computer 

Conferencing,  Draft,  1993 

TIU-TSXAae  MHS  Management:  Access  Unit  Entity,  Draft,  1993  (approval  target  1995-1996) 

ITU-TS  XAagc  Information  Technology  •  Communication  -  Message  Handling  System  (MHS):  Group 
Communication,  Draft,  1993 

mi-TSX.4cm  MHS  Management:  Configuration  Management  Function,  Draft,  1993  (approval  target  1995-1996) 

ITU-TS  Xxp  Information  Technology  -  Message  Handling  Systems  -  PICS  Proforma  for  EDIMG,  Draft,  1993 

(approval  target  November  1994) 

mJ-TSX.4fa  MHS  Management:  Fault  Management  Function,  Draft,  1993  (approval  target  1995-1996) 

ITU-TS  X.4gm/ITU-TS  Xinf  MHS  Management:  Information  and  Functional  Overview,  Draft,  1993  (approval  target 
1995-1996) 

ITU-TS  X.4ma  MHS  Management:  Accounting  Management,  Draft,  1993  (approval  target  November  1994) 

ITU-TS  X4m»  MHS  Management:  Message  Store  Entity,  Draft,  1993  (approval  target  1995-1996) 

ITU-TS  X.4mma  MHS  Management:  Model  and  Architecgture,  Draft,  1993  (approval  target  November  1994) 

ITU-TS  X.4mo  MHS  Management:  MTA  Management,  Draft,  1993  (approval  target  1995) 

ITU-TS  XApm  MHS  Management:  Performance  M'tagement  Function,  Draft,  1993  (approval  target  1995-1996) 

ITU-TS  X.4sm  MHS  Management:  Security  Management,  Draft,  1993  (approval  target  June  1995) 

ITU-TS  XAue  MHS  Management:  User  Agent  Entity,  Draft,  1993  (approval  target  1995-1996) 


H.  MESSAGE  ORIENTED  TEXT  INTERCHANGE  SYSTEM  (MOTIS):3* 


IMS  8505 
DIS  8883 

DIS  9065 

ISOflEC  10021-1* 

ISOflEC  10021-2* 


ISOflEC  10021-3* 
ISOflEC  10021-4* 


ISOflEC  10021-5* 
ISOflEC  10021-6* 
ISOflEC  10021-7* 


ISOflEC  10021-11 
ISOflEC  10021-12 
ISOflEC  10021-13 
ISOflEC  10021-14 
ISOflEC  10021-15 
ISO  10538 
SC21  N  7144 


Functional  Description  and  Service  Specification  for  Message  Oriented  Text  Interchange  Systems 
Message  Oriented  Text  Interchange  System,  Message  Transfer  Sublayer.  Message  Interchange 
Service  and  Message  Transfer  Protocol 

Message  Oriented  Text  Interchange  System  (MOTIS)  User  Agent  Sublayer  -  Interpersonal 
Messaging  User  Agent  -  Message  Interchange  Formats  and  Protocols 
MODS  -  Part  1:  System  and  Service  (X.400) 

Cor  1-5  MODS,  Technical  Corrigenda  1-5 

MODS-  Part  2:  Overall  Architecture  (X.402) 

PD  AM  1  Representation  of  Oflt  Addresses  for  Human  Exchange 

PDAM  2  Minor  Enhancements 

Cor  1-4  MODS.  Technical  Corrigenda  1-4 

MODS  •  Part  3:  Abstract  Service  Definition  Conventions  (X.407) 

Cor  1  MODS,  Technical  Corrigendum  1 

MODS,  Part  4:  Message  Transfer  System  -  Abstract  Service  Definition  and  Procedures  (X.411) 
PDAM  1  Minor  Enhancements 

Cor  1-5  MODS,  Technical  Corrigenda  1-5 

MODS  -  Part  5:  Message  Store  -  Abstract  Service  Definition  (X.413) 

Cor  1-5  MODS,  Technical  Corrigenda  1-5 

MODS  -  Part  6:  Protocol  Specifications  (X.419) 

Cor  1-5  MODS,  Technical  Corrigenda  l-S 

MODS  -  Part  7:  Interpersonal  Message  System  (X.420) 

PDAM  1  Minor  Enhancements 

Cor  1-5  MODS,  Technical  Corrigenda  1-5 

MODS  •  Part  11:  MTS  Routing 

MODS  -  Part  12:  PICS  Proforma  for  Message  Transfer  Protocol 
MODS  -  Part  13:  PICS  Proforma  for  Message  Transfer  Access  Protocol 
MODS  •  Part  14:  PICS  Proforma  for  Message  Store  Access  Protocol 
MODS  -  Part  15:  PICS  Proforma  for  Interpersonal  Messaging 
Control  Functions  for  Text  Communication 

liaison  Statement  to  SC18  Concerning  Mapping  of  Systems  Management  Object  Management 
Function  onto  MODS 


I.  MANUFACTURING  MESSAGE  SPECIFICATION: 

ISO  9506-1  Manufacturing  Message  Specification,  Part  1:  Service  Definition 

AD  1  Data  Exchange,  1993 

ISO  9506-2  Manufacturing  Message  Specification,  Part  2:  Protocol  Specification 

AD  1  Data  Exchange,  1993 

ISO  9506-3  Manufacturing  Message  Specification,  Part  3:  Companion  Standard  for  Robotics 

ISO  9506-4  Manufacturing  Message  Specification,  Part  4:  Companion  Standard  for  Numerical  Control 

3®  DIS  1505*.  DCS  8883*.  and  DIS  9065*  have  been  superceded  by  the  other  standards. 
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J.  FILE  TRANSFER,  ACCESS  AND  MANAGEMENT  (FTAM): 

ISO  1571-1*  FTAM,  Part  1:  Gaoerai  Introduction,  Second  Edition  (incorporating  all 

AM  1  Filestore  Management 

AM  2  Overlapped  Access 

AM  3  Service  Enhancement 

WDAM4  Security  Enhancement 

Cor  1  Technical  Corrigendum  1 

WD  1571-1.2  FTAM,  tat  1:  General  Introduction,  Edition  2 

ISO  1571-2*  FTAM.  Part  2:  Virtual  Filestore  Definitioo 

AM  1  Filestore  Management 

AM  2  Overlapped  Access 

PDAM3  Service  Enhancement 

WDAM  4  Enhancement  to  FTAM  Security  Servioes  (Project  SUSPENDED) 

Cor  1  Technical  Corrigendum  1 

WD  1571*24  FTAM,  Part  2:  Virtual  Filestore  Definition.  Edition  2 

ISO  SS71*3e  FTAM,  Part  3:  Hie  Servica  Definition 

AM  1  Filestore  Management 

AM  2  Overlapped  Access 

AM  3  Service  Enhancement 

WDAM  4  Security  Enhancement  (Project  SUSPENDED) 

Cor  1-2  Technical  Corrigenda  1-2 

WD  *571-34  FTAM,  Part  3:  Hie  Service  Definitioo,  Edition  2 

ISO  1571-4*  FTAM,  Part  4:  File  Protocol  Specification 

AM  1  Filestore  Management 

AM  2  Overlapped  Access 

AM  3  Service  Enhancement 

AM  4  Defect  Report  Changes 

WDAM  5  Security  Enhancement  (Project  SUSPENDED) 

Cor  1  Technical  Corrigendum  1 

WD  1571-44  FTAM,  Part  4:  Hie  Protocol  Specification.  Edition  2 

ISO  *571-5*  FTAM.  Part  5:  Protocol  Implementation  Conformance  Statement  Proforma 

PDAM 1  Hies  tore  Management 

WDAM  2  Overlapped  Access  (project  under  reassessment) 

WDAM  3  Service  Enhancement  (to  be  programed  as  a  Technical  Corrigenda) 
WDAM4  Security  Enhancement  (Project  SUSPENDED) 

WD  1571-54  FTAM,  Part  5:  Protocol  Implementation  Conformance  Statement  Proforma,  Edition  2 

ISCMBC  10170-1*  Conformance  Teat  Suite  for  the  FTAM  Protocol,  Part  1:  Teat  Suite  Structure  and  Teat  Putpoam 

WD  10170-2  Confonnanoe  Test  Suite  for  the  FTAM  Protocol,  Part  2.  FTAM  Abstract  Test  Suite 

WD  10170-3  Conformance  Test  Suite  for  the  FTAM  Protocol,  Part  3:  ACSE  Abstract  Test  Suite  Embedded  Under 

FTAM 

WD  101704  Conformance  Test  Suita  for  the  FTAM  Protocol,  Part  4:  Presentation  Abstract  Test  Suite  Embedded 

Under  FTAM 

WD  10170-5  ConforaaaoM  Teat  Suite  for  the  FTAM  Protocol,  Part  5:  Session  Abstract  Teat  Suite  Embedded  Under 

FTAM 

ISOABC1SP  10607-1*  ISPs  AFT  an  •  File  Transfer,  Access,  end  Management,  Pert  1:  Specification  of  ACSE, 
Proeentotion  tad  Session  Protocols  for  the  Use  by  FTAM 

DAM  1  Additional  Specifications  for  COBOL  Document  Types 

ISOflBC  ISP  10607-2*  ISPs  AFT  an  •  File  Transfer,  Access,  sad  Management,  Part  2:  Definition  of  Document  Types. 
Constraint  Sets  and  Syntaxes 

DAM  1  Additional  Definitions 

DAM  2  Additional  Specifications  for  COBOL  Docuroeat  Types 
DAM  3  FTAM  Constraint  Set  sad  Document  Type  for  COM 
lSQflBC  ISP  10607-3*  ISPs  AFT  an  •  Hie  Transfer.  Access,  and  Management,  Part  3:  AFT  11  -  Simple  File  Transfer 
Service  (Uurtroctured) 

BQmC  ISP  106074*  ISPs  AFT  na  -  Hie  Transfer,  Access,  end  Management,  Part  4:  AFT  12  •  Positional  Hie  Transfer 
Service 

DAM  l  Additional  Specifications  for  COBOL  Document  Types 

ISOflBC  ISP  10607-5*  ISPs  AFT  aa  •  Hie  Daasfer,  Access,  and  Management,  Part  5:  AFT  22  -  Positional  Hie  Access 
Service 

DAM1  Additional  Specifications  for  COBOL  Document  Typro 

BGflBC  BP  10607-6*  ISPs  AFT  an  •  Hie  Transfer,  Access,  and  Management,  Part  6:  AFT  12  -  File  Management  Service 
ISOflBC  ISP  10607-x  ISPs  AFT  na  •  File  Transfer,  Access  and  Management,  Part  x:  AFT  13  •  Fall  File  Transfer 
(HtoratcUctl),  Draft,  1993 
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UNCLASSIFIED 


DOfflC  ISP  10607-y 

ISOABC  ISP  10607-z 

SC21  N  6224 
SCSI  N  6225 
SCSI  N6M2 
SCSI  N  6111 
SCSI  N  6879 
SCSI  N  6964 
SCSI  N  7160 
SCSI  N  7162 
SCSI  N  8236 
SCSI  NS356 
SC31/WG6N  1159 


UP*  AFT  mi  -  Fite  Transfer,  Accra  and  Management,  Put  y:  AFT  23  -  MI  FOe  Accra 
(HmrUciI),  Draft,  1993 

ISPi  AFT  an  •  Fite  Transfer,  Accra  and  Manag ament,  Pat  z:  AFT  4  •  Fiteetor*  Min— it 
Profile*,  Draft.  1993 

Propoeed  EMFACT/FTAM  Document  Type 

Reeponee  to  Liaison  ftan  JTCI/SC24/WG3  about  COM  Document  Type* 

Problems  with  Certifying  FT AM  Implementation  as  Conformant 
FTAM  Aspects  of  Security 

Liaiaoa  Statement  to  SCS1/WQ6  FTAM  from  SC18  on  MHS  Fite  Tfcaoefar  Body  Pat  Type 
Clat*  of  Mapping*  from  a  Single  ASN.l  Type  to  an  FTAM  Document  Type 
FTAM  Security  bane* 

Stain*  of  Project  JTC1.21. 12.08.02,  FTAM  Virtual  Filestore  Service  Enhancements 
liaiaoa  Statement  Regarding  FTAM  Abatract  Teat  Suite*,  EWOS/EO  FT,  October  1993 
Draft  Technical  Corrigenda  to  ISO  8571,  FTAM 

Propoaal  for  a  New  Work  Item  on  a  Claes  of  Mapping*  from  a  Single  ASN.l  Type  to  an  FTAM 
Document  Type 


K.  VIRTUAL 
ISO  9040* 


ISO  9041-1* 


ISO  9041-2* 
ISOAEC  10739-1 

pDISP  11184-1 

pDISP  11184-2 

pWSP  11184-3 

pDISP  11184-4 

pDISP  11184-5 

pDISP  11184-6 

pDISP  11184-7 

pWSP  11185-1 

pWSP  11185-2 

pWSP  11185-3 

pWSP  11185-4 
pWSP  11185-5 
pWSP  11185-6 
pWSP  11185-7 
pWSP  111854 
pWSP  11185-9 
pWSP  11185-10 
pWSP  11185-11 

Appendix  D 


TERMINAL  (V T): 

Virtual  Terminal  Service  -  Base  Class 

AM  2*  Additional  Functional  Units 

Car  1-3  Technical  Corrigenda  1-3 

Virtual  Terminal  Protocol  -  Basic  Class 

AM  2*  Additional  Functional  Unit* 

Cor  1-2  Technical  Corrigenda  1-2 

Virtual  Terminal  (VT)  Protocol,  Part  2:  VT  PICS  Proforma 

Conformance  Test  Suite  for  9041  -  Virtual  Terminal  Basic  Class  Protocol,  Part  1:  Teat  Suite 
Structure  and  Test  Purposes 

ISPs  FVT  Inn  -  Virtual  Terminal  Basic  Ora  -  Register  of  VTE  Profiles.  Part  1:  PVT  121,  S-mode 
Form*  VTE  profile,  1993 

ISPs  FVT  Inn  -  Virtual  Terminal  Basic  Class  -  Register  of  VTE  Profile*,  Part  2:  FVT  122,  S-mode 
Paged  VTE  Profile,  1993 

ISPs  FVT  Inn  -  Virtual  Terminal  Basic  Class  -  Register  of  VTE  Profile*.  Part  3:  FVT  111.  A-eude 
Telnet  Profile 

ISPs  FVT  Inn  -  Virtual  Terminal  Baric  Class  -  Register  of  VTE  Profile*.  Part  4:  FVT  112,  A-mode 
Scroll  VTE  Profile 

ISPs  FVT  Inn  -  Virtual  Terminal  Basic  Clan  -  Register  of  VTE  Profile*,  Part  5:  FVT  113,  A-mode 
CU  l  l  X.3  PAD  Interworking 

ISPs  FVT  Inn  -  Virtual  Terminal  Basic  Class  -  Register  of  VTE  Profile*,  Part  6:  FVT  114,  A-mode 
Transparent  VTE  Profile 

19b  FVT  Inn  •  Virtual  Terminal  Basic  Class  •  Register  of  VTE  Profile*.  Fart  7:  FVT  115.  A-mode 
General  trod  Telnet  VTE  Profile,  1993 

ISPs  FVT  2nn  •  Virtual  Terminal  Basic  Class  -  Register  of  VT  Control  Objects,  Part  1:  FVT  211, 
FVT  212,  Sequenced  and  Unsequencad  Application  Control  Objects,  1993 
ISPs  FVT  2nn  -  Virtual  Terminal  Basic  CUss  -  Register  of  VT  Control  Objects,  Part  2:  FVT  213, 
FVT  214,  Sequenced  and  Unsequencad  Terminal  Control  Objects,  1993 

ISPs  FVT  2nn  -  Virtual  Terminal  Baric  Clra  •  Register  of  VT  Control  Objects,  Part  3:  FVT  215, 
FVT  216,  Application  RIO  Record  Locating  Control  Object  and  Terminal  RIO  Record  Notification 
Control  Object,  1993 

ISPs  FVT  2nn  -  Virtual  Terminal  Basic  Clra  -  Register  of  VT  Control  Object*.  Part  4:  FVT  217, 
Horizontal  Tabulation  Control  Object,  1993 

ISPs  FVT  2on  •  Virtual  Terminal  Basic  Class  •  Register  of  VT  Control  Objects,  Part  5:  FVT  218, 
Logical  Image  Control  Object,  1993 

ISPs  FVT  2nn  -  Virtual  Terminal  Basic  Ora  •  Register  of  VT  Control  Objects,  Part  6:  FVT  219, 
Status  Message  Control  Object,  1993 

ISPs  FVT  2nn  •  Virtual  Terminal  Baric  CUss  -  Register  of  VT  Control  Objects,  Part  7:  FVT  220, 
Entry-control  Control  Object,  1993 

ISPs  FVT  2an  •  Virtual  Terminal  Basic  Clra  -  Register  of  VT  Control  Objects,  Part  8:  FVT  221, 
Forms  Field  Entry  Instruction  Control  Object  (FEICO)  No.  1, 1993 

ISPs  FVT  2nn  -  Virtual  Terminal  Basic  Clais  -  Register  of  VT  Control  Object*.  Pm  9:  FVT  222. 
Paged  Field  Entry  Instruction  Control  Object  (FEICO)  No.  1, 1993 

ISPs  FVT  2nn  -  Virtual  Terminal  Basic  Claes  -  Register  of  VT  Control  Objects,  Pwt  10:  FVT  231, 
Forme  Field  Entry  Pilot  Control  Object  (FEPCO)  No.  1. 1993 

ISPs  FVT  2nn  -  Virtual  Terminal  Basic  Class  -  Register  of  VT  Control  Object*.  Part  II:  FVT  232, 
Paged  Field  Entry  Pilot  Control  Object  (FEPCO)  No.  1. 1993 
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pDISP  1 1183-12 
pDISP  U18S-13 
pDISP  11185-14 
pDISP  11185-15 
pCHSP  11185-16 
pDISP  11185-17 
pDISP  11186-1 
DISP  11187-1* 
MSP  11187-2* 
pDISP  11187-3 
pDISP  11187-4 
pMSP  11187-6 
pDISP  11187-7 
pDISP  11187-8 
pDISP  11187-9 
pDISP  11187-10 


ISPi  FVT  2an  •  Virtual  Tenninal  Basic  Class  •  Register  of  VT  Control  Objects,  Part  12:  FVT  251. 
Tsnninal  Conditions  Control  Object  No.  1 

ISPs  FVT  2m  •  Virtual  Terminal  Basic  Class  •  Register  of  VT  Control  Objects,  Part  13:  FVT  2111, 
Waiting  Tuna  Control  Object  (pDISP  expected  1995) 

ISPs  FVT  2m  •  Virtual  Terminal  Basic  Class  -  Register  of  VT  Control  Objects,  Part  14:  FVT  2112. 
Printer  Control  Object,  1993 

ISPs  FVT  2m  -  Virtual  Terminal  Basic  Class  •  Register  of  VT  Control  Objects,  Part  IS:  FVT  2113, 
Raid  Definition  Control  Object,  1993 

ISPs  FVT  2m  -  Virtual  Tenninal  Basic  Class  -  Register  of  VT  Control  Objects,  Part  16:  FVT  2114, 
Terminal  Signal  Titles  Control  Object,  1993 

ISPs  FVT  2m  •  Virtual  Terminal  Basic  Class  -  Register  of  VT  Control  Objects,  Part  17:  FVT  2115, 
Form  Help  Text  Control  Object,  1993 

ISPs  FVT  3m  -  Virtual  Terminal  Basic  Class  •  Register  of  Assignment  Type  Definitions,  Past  1: 
FVT  321,  Foot  Assignment  Type  No.  1 

ISPs  AVT  In,  AVT  2n  -  Virtual  Terminal  Basic  Class  -  Application  Profiles,  Part  1:  AVT  22.  S-mode 
Forms  Application  Profile,  1993 

ISPs  AVT  In,  AVT  2n  •  Virtual  Tenninal  Basic  Class  •  Application  Profiles,  Part  2:  AVT  23.  S-mode 
Paged  Application  Profile,  1993 

ISPs  AVT  In,  AVT  2n  •  Virtual  Terminal  Basic  Class  -  Application  Profiles,  Part  3:  S-mode  ISPICS 
Requirements  List  No.  1 

ISPs  AVT  In,  AVT  2n  -  Virtual  Terminal  Basic  Class  •  Application  Profile*,  Part  4,  S-mode  ISPICS 
Requirements  (IPRL)  List  No.  1,  Supporting  Layers  List  No.  1 

ISPs  AVT  In,  AVT  2n  -  Virtual  Terminal  Basic  Class  •  Application  Profiles,  Part  6:  AVT  13, 
A-mode  Scroll  Application  Profile 

ISPs  AVT  In,  AVT  2n  •  Virtual  Terminal  Basic  Class  -  Application  Profiles,  Part  7:  AVT  14. 
A-mode  CCTTT  X.3  PAD  Application  Profile 

ISPs  AVT  In,  AVT  2n  -  Virtual  Terminal  Basic  Clast  -  Application  Profiles,  Part  8:  AVT  IS, 
A-mode  Transparent  Application  Profile 

ISPs  AVT  In.  AVT  2n  •  Virtual  Terminal  Basic  Class  -  Application  Profiles,  Part  9:  AVT  16. 
A-mode  General  toed  Telnet  Application  Profile,  1993 

ISPs  AVT  In,  AVT  2n  -  Virtual  Terminal  Basic  Class  -  Application  Profiles,  Part  10:  AVT  17, 
A-mode  ISPICS  Requirements  List  No.  1 


L.  TERMINAL  MANAGEMENT  (TM),  VISUAL  DISPLAY  TERMINAL  (VDT),  AND  X- 
WINDOWS: 


ISO  9241-1 
ISO  9241-2 

ISO  9241-3 

MS  9241-4 

CD  9241-5 

CD  9241-6 

CD  9241-7 

CD  92414 

CD  9241-9 

WD  9241-10 

CD  9241-11 

CD  9241-12 

WD  9241-13 
CD  9241-14 
WD  9241-15 

WD  9241-16 
Appendix  D 


Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals.  Part  1:  Introduction 
Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals.  Part  2:  General  Guidance 
on  Task  Requirements 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  3:  Visual  Display 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  4:  Keyboard 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  5:  Workstation 
Layout  and  Postural  Requirements 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  6:  Environmental 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  7:  Display 
Requirements  with  Reflections 

Brgonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  8:  Requirements  for 
Displayed  Colon 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  9:  Requirements  for 
Non- Keyboard  Input  Devices 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  10:  Dialogue 
Principles 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  11:  Usability 
Statements 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  12:  Presentation  of 
Information 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  13:  User  Guidance 
Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  14:  Menu  Dialogues 
Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  15:  Command 
Dialogues 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  16:  Direct 
Manipulation  Dialogues 
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UNCLASSIFIED 
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UNCLASSIFIED 


WD  9241-17 

XX  9241-11 

XX  9241-19 

CD  101S4-U 
WD  101S4-2 
WD  10184-3 
DIS  11730 
SC21  N  4199 


Ergonomic  luriwitt  fat  Office  Wort  with  Visual  Display  Twmhrale,  Ptot  17:  Foau-PiOfog 
Dialogue. 

Ergonomic  Requiremants  for  Office  Work  with  Visual  Diepiey  Twminsli.  Pvt  It:  Qusstiou  and 
Answer  Dialogues 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals  Part  19:  Natural 
Language  Dialogues 

Terminal  Management  •  Model  (project  cancelled) 

Terminal  Management  -  Service  (project  cancelled) 

Terminal  Management  •  Protocol  (project  cancelled) 

Form  Interface  Management  System  (F1MS) 

Comments  on  the  Integration  of  X-Windows  into  the  OSI  Environment 


M.  JOB  TRANSFER  AND  MANIPULATION  (JTM): 

ISQflEC  M31  Job  Transfer  and  Manipulation  Concepts  and  Services 

ISOflEC  8832  Specification  of  the  Basic  Class  Protocol  for  Job  Tnmsfer  and  Manipulation 


N.  TELEMATIC  SERVICES: 


mj-T5F.ll 
rru-TSFAo 
rru-TSFAi 
IIU-TS  F59 
ITU-TS  F.73 

nU-TSFSO 

ITU-TS  F.82 

ITU-TS  FA6 
nU-TSFJ7 

ITU-TS  F.104 
nU-TSF.lll 

ITU-TS  F.150 
ITU-TS  F.200 
ITU-TS  F.200C 
ITU-TS  F.201  Rev  1 


Continued  Availability  of  Traditional  Services 
International  Public  Telemessage  Service 

Interworking  Between  the  Telemessage  Service  and  the  International  Public  Telegram  Service 
General  Characteristics  of  the  International  Telex  Service 

Operational  Principles  for  Communication  Between  Terminals  on  Telex  Networks  and  Data 
Terminal  Equipment  on  Packet  Switched  Public  Data  Networks 

Basic  Requirements  for  Interworking  Relations  Between  the  International  Telex  Service  and  Other 
Services 

Operational  Provisions  to  Permit  Interworking  Between  the  International  Telex  Service  and  the 
INTEX  Service 

Interworking  Between  the  International  Telex  Service  and  Videotex  Service 

Operational  Principles  for  the  Transfer  of  Mesaages  from  Terminals  of  the  International  Telex 

Service  to  Group  3  Facsimile  Terminals  Connected  to  the  Pubbc  Switched  Telephone  Network 

International  Leased  Circuit  Services  •  Customer  Circuit  Designations 

Principles  of  Service  for  Mobile  Systems 

Service  and  Operational  Pro  visions  for  the  INTEX  Service 

Teletex  Service 

Telefax  Service,  Annex  C:  Mixed  Mode  of  Operation 
Internetworking  Between  the  Teletex  Service  and  the  Telex  Service 


O.  INFORMATION  RESOURCE  DICTIONARY  SYSTEM  (IRDS): 


DP  8800-1 

ISOflBC  10027 
WD  10027.2 

ISOflBC  10728 


WD  10728-2 
SC21  N  6231 

SC21  N62S2 
SC21  N  6233 
SC21  N  6237 
SC21  N  7171 
SC21  N  7181 
SC21  N  7182 
SC21  N  7191 
SC21  N  7201 
SC21  N  7203 
SC21N7486 
SC21N8202 


Information  Resource  Dictionary  System  (IRDS).  Part  1:  Commaud  language  and  Panel  luierferi 
(project  cancelled) 

IRDS  Framework.  June  1990 

Information  Resource  Dictionary  System  (IRDS)  Framework.  Edition  2  (revision  to  address  new 
requirements  and  alignment  with  RMDM,  SQL,  RDA,  Directory,  and  ODP) 

IRDS  -  Services  Interface 

PDAM 1  C  Language  Binding 

WDAM  2  Ada  Language  Binding 

IRDS  -  Services  Interface.  Edition  2 

Proposed  New  Question  on  the  IRDS  Definition  Level  Content  Stanched  for  5emsullr  Unification 
Meta  Model  (SUMM) 

Revision  of  the  IRDS  Framework 

Proposed  New  Question  on  the  Approach  to  Remote  IRDS  Access 

Recommendation  on  NWI  for  Stored  DBL  Procedures 

Proposed  NP  for  Guidelines  for  the  Design  of  IRDS  Content  Module* 

Proposed  Draft  Answer  to  Question  Q3/009  -  Remote  IRDS  Access 
Liaison  Statement  to  ECMATC33  on  IRDS/PCTE 

Lhdeou  Statement  to  ISO  TC184/SC3  on  Reference  Model  wad  IRDS  for  Automation 

Amendment  to  ISO  10728  for  C  language  Binding 

DUDS  Framework  Revision 

Draft  IRDS  Conceptual  Schema 

Working  Draft  of  IRDS  Services  Interface  Extensions 
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UNCLASSIFIED 


SC21  N  8204 
SC21/WG3  N  1279 
SC21/WQ3  N  1283 
SC21/WQ3  N  1406 


Working  Draft  of  IRDS  Framework  (Revision  of  ISO  10027:1990) 

Report  of  >IiiHo|  CD1F/U7S/PDES  Information  Coordination 
DtDS  Soviow  Interface  Extensions  -  Design  Document 

Agreed  Scope  of  Work  for  (be  Revision  of  the  IRDS  Framework  (IS  10027),  Ottawa 


P.  REMOTE  DATABASE  ACCESS  (RDA): 


ISO  9579-1* 
ISO  9579-2* 


CD  9579-3 
SC21N7177 
SC21  N  7199 
SC21N7202 


Remote  Detsbisr  Access  (RDA),  Part  1:  Generic  Model,  Service,  and  Protocol 
WDAM1  Generic  RDA 

Remote  Detabaae  Access  (RDA),  Part  2:  SQL  Specialization 
PDAM1  Support  for  SQU 

WDAM  2  RDA  Support  for  Shared  DBL  Statements 

Remote  Database  Access  (RDA),  Part  3:  SQL  PICS  Proforma 

Propoeed  New  Work  Item  for  Remote  Database  Access  (RDA),  Part  3:  IRDS  Specialization,  Ottawa 
Remote  Database  Access  (RDA) 

Progression  of  Work  on  RDA  Suspend/Resume  and  Dialogue  Recovery,  ISO/IEC  JTC1/SC21/WG3 

Meeting.  Ottawa 


Q.  DATA  MANAGEMENT  CONCEPTS: 


DCS  7826-1 
DIS  7826-2 
ISCVTR  9007 
ISO/IEC  10092* 
CD  11179-1 
CD  11179-2 
DIS  11179-3 
DIS  11179-4 
CD  11179-3.2 
CD  11179-6 
J*3ST‘ 

SC21N197 

SC21N236 

SC21N5137 

SC21  N  6614 
SC21  N  6653 

SC21N6728 

SC21N6801 

SC21N6929 

SC21N694S 

SC21N6951 

SC21N69S2 

SC21N69S5 

SC21  N  7206 
SC21N7392 

SC21N8060 
SC21  N  8211 
SC21  N  8109 
SC21/WQ3  N  1349 
SC21/WG3  N  1371 
SC21/WQ3  N  1653 

SC21/WG3  N  1655 
SC21/WQ3  N  1660 


Representation  of  Date  Elements,  Part  1,  November  1993 

Representation  of  Data  Elements,  Part  2,  November  1993 

Concepts  and  Terminology  for  the  Conceptual  Schema  and  the  Information  Baae 

Reference  Model  of  Data  Management 

Coordination  of  Data  Elements,  Part  1,  Novem  bar  1993 

Coordination  of  Data  Elements,  Part  2,  November  1993 

Coordination  of  Data  Elements,  Part  3,  Novem  ber  1993  (balloting  ended  February  1994) 

Coordination  of  Data  Elements,  Part  4,  Janaury  1994 

Coordination  of  Data  Elements,  Part  5.  Janaury  1994 

Coordinalioo  of  Data  Elements,  Part  6.  Novem  ber  1993 

Database  Management  Standards:  Status  and  Applicability 

Concepts  and  Terminology  for  the  Conceptual  Schema  and  the  Information  Baae,  7C97/SC5 
Assessment  Guidelines  for  Conceptual  Schema  Language  Proposals,  TC97/SC2 1/WG5-3 
Data  Management  Export/Import  for  SQL  and  IRDS  (to  become  a  three-part  standard:  Framework; 
Facilities;  Facilities  for  IRDS) 

SC21  Action  to  Address  Problems  of  Data  Modelling  Standards  Coordination 

Various  Contributions  to  the  ISCWIEC  JTCI/SC21  Special  Group  Meeting  on  Conceptual  Scheme 
and  Common  Data  Modelling  Facilities 

Summary  of  Planned  Contributions  to  the  Renesse  Special  Meeting  on  Conceptual  Schema 
Facilities  and  Common  Data  Modelling  Fecilities 

Comments  on  SC21  Recommended  Action  to  Address  Problems  of  Data  Modelling  Standards 
Coordination 

ITC1  National  Body  Comments  Received  on  JTC1  N  1756,  "Request  for  Review  and  Comment  on 
the  SC21  Recommended  Action  to  Address  Problems  of  Data  Modelling  Standards  Coordination" 
Recommendations  and  Proposed  Work  on  Conceptual  Schema  and  Data  Modelling  Facilities 
Reference  Material  on  Conceptual  Schema  and  Common  Data  Modelling  Facilities 
Report  of  the  9-13  March  1992  Renesse  Meeting  of  the  SC21  Special  droop  on  Conceptual  Schama 
and  Common  Data  Modelling  Facilities 

Stocktaking  of  Standards  and  Standards  Projects  Which  Make  Use  of  a  Data  Modelling  Facility  or  of 
ft  Cooceptoal  SdNDi 

Proposal  for  an  SC21  SWG  on  Modelling  Facilities 

US  Contribution  to  the  SC21  Special  Working  Group  Meeting  on  Modelling  Facilities.  7-11 
December  1992  in  Namur,  Belgium 
Conceptual  Schema  Modeling  Facility 

Draft  Answer  to  Question  Q3/007,  "Support  for  Distributed  Database  Systems" 

Proposed  New  Question  Q3/011,  "Harmonization  of  Ctient/Server  Capabilities" 
liaison  Report  June  1991-May  1992,  JTC1/SC7  Software  Engineering 
Discussion  between  JTC1  SC21/WG3  and  ISO  TC  184/SCS/WG4 

RMDM,  SQL92  and  SQL3  Mapping  Final  Reports — Summary  and  Conclusions,  Final  VI. 1, 

Inkrou  Inc.,  August  1993 

Liaison  Statement  to  CSMF  RG,  December  1993 

Applicability  of  the  ISO  Reference  Model  of  Data  Management  (ISO  10032:1993)  to  Client  Server 
Computing.  Dr.  T.  William  OUe.  October  1993 
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BO  9075:  mt 
ISO  9075:1992 

WD9075-X 
WD  9075-y 
WD  90753 
CD  12227 
SC21  N  6737 
SC21  N  6759 
SC21  N  6760 
SC21N6I92 
SC21N6931 
SC21  N  7179 
SC21  N  7180 
SC21  N  7183 
SC21  N  7185 
SC21  N  7186 
SC21NS2Q5 

SC21/WQ3  N  1298 
SC21/WG3  N  1345 


SC21/WQ3  N  1430 
SC21/WQ3  N  1647 
SC21/W03  N  1613 
SC21/WQ3  N  1614 


Database  l.mgnaga  SQL 

Database  Language*  -  SQL  (known  as  SQL2  or  SQL-92) 

Cor  1  Technical  Corrigendum  1.  January  1994 

Database  Language*  •  SQL.  hft  x:  SQL  CaU  Level  Intarfscs  (CU) 

Dtabaa a  Languages  -  SQL.  Part  y:  Persistent  SQL  Modules 

Database  Languages  -  SQL3 

SQL  Ada  Modide  Description  Languaga  (SAMaDL) 

Object  Oriented  Task  Group  Final  Report 
Recommendrtion  on  SQL2  Progression  (ISQflEC  MS  9075) 

Mtoutas  of  the  SQL2  Editing  Meeting,  Kawagoc 

Uaiaon  Statement  to  SC21/WG4  on  Atomic  Transaction  Interfaces 

Waiting  Draft  for  SQL-3,  Interim  Database  Languages  Meeting.  Japan 

SQL  Multimedia  and  Application  Packages 

Proposed  Draft  Answer  to  Question  Q 3/001  -  Object  Database 

Liaison  Statement  to  EWOS/EG  DBE  on  Profiling  SQL/RDA 

Uaiaon  Statement  to  JTC1/SC14  on  Data  Elements 

liaison  Statement  to  SC18  on  Full-Text  Manipulation 

SQL  Multimedia  and  Hypermedia  Application  Packages  (SQL/MM)  Project  Plan  (Revised), 

SC21/WG3,  September  1993 

New  Project  Proposal:  SQL  ADT  Packages 

Letter  to  Brace  Catley  Convenor,  JTC1/SC21/WG3,  Government  Telecommanicatiens 
Agency/VPD,  Ottawa  Canada,  EWOS,  on  the  European  Workshop  for  Open  Systems.  Expast  Group 
on  Database  Enquiry 
DBL  Status  Report 

ISO  SQL  Multimedia  and  Application  Packages  (SQUMM),  Part  1:  Framework,  Working  Dwft 
ISO  SQL  Multimedia  and  Application  Package*  (SQL/MM).  Part  2:  FuB-Tsoo.  Wasting  Draft 
ISO  SQL  Multimedia  and  Application  Packages  (SQL/MM).  PM  3:  Spatial.  Wotting  Draft 


S.  DISTRIBUTED  TRANSACTION  PROCESSING  (TP): 

ISOflBC  10026-1*  Distributed  Transaction  Processing  (IPX  Part  1:  Model  (XJ60:1992) 

pDAM  1  Amendment  1:  ConuniUMBt 

WDAMs  Draft  Amendments  to  Parts  1-3:  Distribneed  Transaction  frortasieg 
Dialogue  Recovery  and  User  Snspaneiow  of  a  Dialogue 
WDAMs  Draft  Amendments  to  Pasta  1-3:  Transaction  Processing  Association 
Pool  Management 

WDAMs  Draft  Amendments  to  Parts  1-3:  Transaction  Processing  Sub- 
Transactions 

WDAMs  Draft  Amendments  to  Parts  1-3:  Transaction  Processing  Separate  Data 
and  Commit  Associations 

WDAMs  Draft  Amendments  to  Parts  1-3:  Traroactiou  Processing  Security 
ISOflBC  10026-2*  Distributed  Transaction  Processing  (TP),  Part  2:  Service  (X.861: 1992) 

PDAM  1  Amendment  1:  Commitment  Optimiaattona. 

ISQflEC  10026-3*  Distributed  Transaction  Processing  (TP),  Part  3:  Transaction  Processing  Protocol  Specification 
(X.862) 

PDAM  1  Amendment  1:  Commitment  Opthstisatione, 

ISQflEC  10026-4  Distribelsd  Transaction  Processing  (TP),  Part  4:  PICS  ftofocau 

ISQflEC  10026-5  Distributed  Transaction  Processing  (TP),  Part  5:  Application  Context  Proforma 

ISQflEC  10026-6  Distributed  Transaction  Processing  (TP).  Part  6:  Unstructured  Data  Transfer 

CD  10026-7  Distributed  Transaction  Processing  (TP),  Part  7:  Message  Queueing 

WD  10026-x  Distributed  Transaction  Processing  (TP),  Part  x:  Dialogue  Recovery 

WD  10026-y  Distributed  Transaction  Processing  (TP),  Part  y.  TP  Association  Pool  Management  Function 

CD  115872  Application  Context  for  Systems  Management  with  Transaction  Processing 

DBF  12061-1  ISPs  ATT  no  -  OSI  Dktributed  Transaction  Processing.  PM  1:  Introduction.  1993 

DBF  12061-2  ISPs  ATP  nn  •  OSI  Distributed  Transaction  Processing.  Part  2:  Support  of  tbs  OSI  TP  APDUs,  1993 

MSP  12061-3  BPS  ATP  an  •  OSI  Distributed  Transaction  Processing,  PM  3:  Support  of  tie  CCR  Protocols.  1993 

MSP  12061-4  BPS  ATT  mi -OSI  Distributed  Transaction  Processing.  PM  4:  Support  of  ACSB.  Presentation  and 

Session  Protocols,  1993 

MSP  12061-5  BPs  ATP  an  •  OSI  Distributed  Transaction  Processing.  Pm  5:  ATP  11,  Application  Supported 

Transactions  with  Polarised  Control,  1993 


Appendix  D 


D-57 

UNCLASSIFIED 


Application  Layer  Standards 


UNCLASSIFIED 


DBF  13061-6 

MSP  12061-7 

DISP  12061-8 

pDBP  12061-9 

pDISP  12061*10 

pDISP  1206M1 

pDISP  12061.x 
pDISP  12061 -y 
SC21N67S6 
SC21  N  71S6 
SCSI  N  716S 
SC21  N  7166 
9C21  N  7167 
SC21  N  7168 
SCai  N  7171 
seal  N  7172 
SC21  N  7173 
SCai  N  717S 
seal  N  7417 
SC21  N  7625 
seal  N  7626 
SC21N7644 
SCSI  N  7672 
SCai  N  7676 
seal  N  8131 
SCai  N  8132 
seal  N  8216 
seal  N  8321 
seal  N  8322 
scatmoi  N  1233 
SC21/WQ5N673 

rru-Tsx.860 
n\I-TSXJ61 
rrUTSX.862 
ITU-TS  X.863 


ISP*  ATP  an  .  OSI  Distributed  Transaction  Prof  i«ii>8.  Pm  6:  ATP  12,  Application  Supported 
Transactions  with  Shared  Control,  1993 

BP*  ATP  an  *  OSI  Distributed  Transaction  Processing.  Pm  7:  ATP  21,  Provider  Supported 
Transaction*  in  Uochaioed  Mode  with  Polariaad  Control.  1993 

ISP*  ATP  no  •  OSI  Distributed  Transaction  Processing,  Pm  8:  ATP  22.  Provider  Supported 
Transactions  in  Unchained  Mode  with  Shared  Control,  1993 

ISPs  ATP  an  -  OSI  Distributed  Transaction  Processing,  Pm  9:  ATP  31,  Provider  Supported 
Transaction!  in  Chained  Mode  with  Polarised  Control,  1993 

ISP*  AIT  an  •  OSI  Distributed  Tran* action  Processing,  Pm  10:  AIT  32,  Provider  Supported 
Transactions  in  Chained  Mode  with  Shared  Control,  1993 

ISPs  ATP  no  •  OSI  Distributed  Transaction  Processing,  Pm  11:  IT  Transaction  Recovery 
Application  Context,  1993 

ISPs  AIT  an  -  OSI  Distributed  Transaction  Processing,  Pm  x:  Systems  Profiling  for  IT,  1993 
ISPs  ATT  an  -  OSI  Distributed  Transaction  Processing,  Pm  T-  Development  of  PTS  for  TP.  1993 
TPfCCR  One-Phase  Coomitment 

Proposed  NP  for  Trans  set  ion  Processing  Abstract  Test  Suites 
TP  Commitment  Optimization  Issues  and  Resolutions 

Requirements  end  Issues  far  the  Scperatioo  of  Dote  end  Commitment  Flow*  in  OSI  TP 
Request  for  Contributions  on  OSI  TP  Subtransections 

ItoaMMt  tor  Comineisu  oo  Ismot  Cdoccnilnf  IT1  Association  Fool  Mansgonsot 

Revised  TP  Teat  Suite  Shucture  and  Test  Purposes 

Osaerel  Principles  for  the  Development  of  TP  Test  Csess 

Open  Issasi  snd  Questions  for  the  Development  of  TP  Test  Caaes 

Helena  Statement  so  SC6  on  Requirement  for  Noo-Blocidiig  Transport  Expedited  Service 

Association  Management  Concepts 

Stelne  of  Wo*  on  the  Separation  of  Date  and  Commit  Flows  in  OSI-TP 
Request  for  Contributions  for  OSI-TP  Subtransections 
TP  CooBtosat  Optimizations  *  Topics  tod  TMr  Resolution 
Revimd  Working  Draft  for  TP  Test  Suite  Stroctura 
Initial  Abstract  Test  Soils  for  TP 

Stems  of  Work  on  the  Sobtransactions  in  OSI  TP.  SC21/WG8,  July  1993 

Stems  of  Work  on  the  Separation  of  Date  and  Commit  Flows  in  OSI  TP.  SC21/WQS,  inly  1993 

Coaftnaanm  Teat  Suite  for  TP  Protocol,  Pm  1:  Test  Soils  Structure  md  Test  Purposes 

Requfaumeut  for  Partial  RoUbach,  USA,  November  1993 

Raapouee  to  SC21  N  8067  on  IT  with  RPC,  USA.  Novmnber  1993 

Use  of  Quality  of  Services  in  ODP  Trader 

Minuses  of  the  IT  Group  Meeting,  Ottawa,  21-29  May  1992 

Distributed  ‘naauction  FsroesasMg:  Modal  (ISO  10026- IX  1992 

Distributed  Transaction  Processing:  Sarvics  (ISO  10026-2X  1992 

Distributed  Transaction  Perocsssing:  Protocol  Specification  (ISO  10026-3X  Draft,  1993 

Information  Technology  -  Opm  Systems  Interconnection  -  Distributed  Transaction  Processing: 

PICS  Profcnna  (BO  100264X  Draft,  1993 


T.  OPEN  DISTRIBUTED  PROCESSING  (ODP): 

WD  10746*1  Basic  Reference  Model  far  Open  Distributed  Processing,  Pm  1:  Overview  and  Guide  to  Uee  (merged 

with  old  107364)  (X.901) 

CD  10746-23  Basic  Reference  Model  for  Open  Distributed  Processing,  Pm  2:  Descriptive  Model  (X.902) 

CD  10746-3.2  Basic  Reference  Model  for  Open  Distributed  Processing.  Pm  3:  Descriptive  Model  (X.903) 

WD  107464  Basic  Reference  Model  for  Open  Distributed  Processing,  Pm  4:  Architectural  Semantics, 

Specification  Techniques,  and  Formalisms  (formerly  User  Model)  (X.904) 

SC21  N  6972  Ml  Answer  to  Q6/2  -  Relationship  Between  the  OSI  Upper  Lay*  Architecture  and  ODP 

SC21N7042  The  RM-ODP  and  Standardization  of  APIs 

SC21  N  7051  Proposed  Draft  Answer  to  Question  Q7/1  on  the  Suitability  of  the  Formal  Description  Z  for  Uee  in 

ODP 

SC21  N  7032  Editing  Instructions  for  ■  Technical  Report  oo  Use  of  FDTs  in  ODP 

9C21N70S7  List  of  Open  md  Resolved  Issues 

SC21  N  7088  Proposed  New  Question  Ql/66  oo  ODP  Conformance  Testing  Methodology 

SC21  N  7423  Draft  First  Report  on  the  New  Wort  Area  on  Programmatic  Interfaces 

SC21  N  8283  Position  on  the  ODP  Standards  Process  snd  Cooperation  with  de  facto  Standards  Organizations, 

AFNOR,  October  1993 

SC21  N  8409  Information  Technology  •  Open  Systems  Interconnection  -  ODP  Trading  Function,  January  1994 

8C21/WG7  N  783  An  Integrated  Approach  to  Trader  Contexts,  August  1993 

SC21/WG7N8U  Relations  of  Formal  Descriptions  of  Different  ODP  Viewpoint  Models,  Angnst  1993 
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UNCLASSIFIED 


SC21/WQ7  N  S21 
SC21/WG7N823 
SC21/WG7  N  836 
SC21SWG7  N  «S2 
SC21/WG7N862 
SC21/WG7N863 
mj-TS  X.901 

mj-TS  X.902 

rru-Tsx.903 

ITU-TS  X.904 
ITU-TS  X* 
ITU-TS  X-tradv 


Diaruesinn  Note  on  RM-ODP  Pm  4.  August  1993 

Joint  Action  Plat  SC2I/WG7  and  WG7-TIU-TSX216/7  (ITU-TS  Format).  August  19*3 

Liaison  Contribution!  for  SC21/WG7,  SC21/WG3,  August  1993 

Outlins  of  Uformatioa  Specification  for  OOP  Trader,  Australis.  October  1993 

An  OOP  Architectural  Semantic!  in  Z,  UK.  October  1993 

An  OOP  Architectural  Semantics  in  LOTOS.  UK.  October  1993 

Basic  Reference  Model  for  Open  Distributed  Processing:  Overview  and  Guide  to  Use 
0 SO  10746-1).  Draft.  1993 

Basic  Reference  Model  for  Open  Distributed  Processing:  Descriptive  Model  (ISO  1G746-2).  Draft. 
1993 

Basic  Reference  Model  for  Open  Distributed  Processing:  Prescriptive  Model  (ISO  10746-3),  Draft. 
1993 

Basic  Reference  Model  for  Open  Distributed  Processing:  Architectural  Sauuutics  (ISO  10746-4), 
Draft.  1993 

Basic  Reference  Model  for  Open  Distributed  Processing:  Use  of  Formal  Description  Technique  for 
ODP,  Draft.  1993 

Basic  Reference  Model  for  Open  Distributed  Processing:  ODP  Trader,  Draft,  1993 


U.  GRAPHICAL  KERNEL  SYSTEM  (GKS): 


ISO  7942  Graphical  Kernel  System  (GKS)  Functional  Description 

AMI  Audit  Trail  Metafile 

ISO  8651-1  GKS  Language  Bindings,  Pm  1:  FORTRAN 

ISO  S631-2  OKS  Language  Bindings,  PM  2:  Pascal 

ISO  1631-3  GKS  Language  Bindings,  PM  3:  Ada 

ISOflBC  S631-4  GKS  Language  Bindings,  PM  4:  C 

ISO  SSQS  GKS  for  Three  Dimensions  (GKS-3D)  Functional  Description 

WDAM1  Name  Set  Addendum 

US  SS06-1  GKS- 3D  Language  Bindings,  Pm  1:  FORTRAN 

DtS  4806-3  GKS-3D  Language  Bindings,  Pm  3:  Ada 

ISQABC  8806-4  GKS-3D  Language  Bindings,  PM  4:  C 


V.  PROGRAMMER'S  HIERARCHICAL  INTERACTIVE  GRAPHICS  SYSTEM  (PHIGS): 

ISO  9392-1  Programmer's  Hierarchical  Interactive  Graphics  System  (PHIGS)  Language  Bindings.  PM  1: 

Functional  Description 

AM  1  PHIGS  Phis  Support 

ISO  9392-2  PHIGS  Language  Bindings,  PM  2:  Archive  File  Format 

AMI  PHIGS  Plus  Support 

ISO  9392-3  PHIGS  Language  Bindings,  Part  3:  Clear-Text  Encoding  of  Archive  File 

AMI  Incorporation  of  PHIGS  Plus 

ISO  9392-4  PHIGS  Language  Bindings,  PM  4:  PHIGS  Plus  [SC24N  224] 

ISOflOBC  9593-1  PHIGS  Language  Bindings,  PM  1:  FORTRAN 

DIS  9393-2  PHIGS  Language  Bindings,  Part  2:  Extended  Pascal 

ISO  9393-3  PHIGS  Language  Bindings,  PM  3:  Ada 

ISO  9593-4  PHIGS  Language  Bindings,  PM  4:  C 


W.  DIALOGUES  WITH  GRAPHICAL  DEVICES: 

ISO  9636-1  Computer  Graphics  -  Interfacing  (CGI)  Techniques  for  Dialogues  with  Graphical  Devices  • 

Functions!  Specification,  Pm  1:  Overview,  Profiles,  and  Conformance 

ISO  9636-2  Computer  Graphics  -  Interfacing  (CGI)  Techniques  for  Dialogues  with  Graphical  Devices  - 

Functional  Specification.  Pm  2:  Control,  Negotiation,  and  Erma 

ISO  9636-3  Computer  Graphics  •  Interfacing  (CGI)  Techniques  for  Dialogues  with  Graphical  Devices  - 

Functional  Specification.  Pm  3:  Output  and  Attributes 

ISO  9636-4  Computer  Graphics  •  Interfacing  (CGI)  Techniques  for  Dialogues  with  Graphical  Devices  - 

Functional  Specification,  Pm  4:  Segmentation 

ISO  9636-5  Computer  Graphics  -  Interfacing  (CGI)  Techniques  for  Dialogues  with  Graphical  Devices  - 

Functional  Specification,  Pm  5:  Input  and  Rr*»«faig 

ISO  9636-6  Computer  Graphics  •  Interfacing  (CGI)  Techniques  for  Dialogues  with  Graphical  Devices  • 

Functional  Specification,  PM  6:  Raster 

WD  9636-8  Computer  Graphics  •  Interfacing  (CGI)  Techniques  for  Dialogues  arith  Graphical  Devices  - 

Functional  Specification,  Part  8:  FORTRAN  Language  Binding  of  CGI 
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WD  9636*11 

US  9637-1 

ISQAEC  9637-2 

US  9637-3 

US  963S-1 

ns  9631-2 
US  9638-3 
HS  9638-4 
US  10641 


Computer  Graphics  •  Interfacing  (CGI)  Techniques  for  Dialogues  with  Graphical  Devices  - 
Functional  Specification,  Fart  11:  C  Language  Binding  of  CGI 

Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Data  Stream  Encoding  -  Part  1: 
Chvactn 

Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Data  Stream  Encoding  -  Pvt  2: 
Binary  Encoding 

Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Data  Stream  Encoding  -  Part  3: 
Clear  Text  Encoding 

Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Language  Bindings,  Part  1: 
FORTRAN 

Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Language  Bindings,  Part  2:  Pascal 
Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Language  Bindings,  Part  3:  Ada 
Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Language  Bindings,  Part  4:  C 
Conformance  Testing  of  Implementations  of  Graphics  Standards 


X.  DOCUMENT  EXCHANGE— ODA,  ODIF,  DOAM,  DFR,  AND  DTAM: 


ISO  1211 

ns  8211.2 

ISO  *613-1* 


ISO  8613-2* 

HS  8613-3 
ISO  >613-4* 
ISO  8613-3* 
ISO  8613-6* 
ISO  8613-7* 
ISO  8613-8* 


CD  8613-9 
ISO  8613-10 


CD  8613-11 
US  8613-12 
ISCMDBC  10031-1 
ISOflEC  10091-2 
ISCMEC  10166-1 
ISQAEC  10166-2 
DQ0BCTR  10183 
CD  10303-11 
pUSP  12064-1 


SC21  N  6227 
SC21  N  6667 

SC21  N  7430 
SC21N8236 


Specification  for  a  Data  Descriptive  Hie  for  Information  Interchange 

Specification  for  a  Data  Descriptive  File  for  Information  Interchange,  Edition  2 

Office  Document  Architecture  (ODA)  and  Interchange  Format,  Part  1:  Introduction  and  General 

Principles 

AM  1  Document  Application  Profile  Proforma  and  Notation 

AM  2  Conformance  Testing  Methodology 

ODA  and  Interchange  Format,  Part  2:  Document  Structures 

PDAD 1  Formal  Specification  of  ODA  Document  Structures 
ODA  and  Interchange  Format,  Part  3:  Abstract  Interface  for  Manipulation  of  ODA  Documents 
ODA  and  Interchange  Format,  Part  4:  Document  Profile 

ODA  and  Interchange  Format,  Pvt  S:  Office  Document  Interchange  Format  (ODIF) 

ODA  and  Interchange  Format,  Part  6:  Character  Content  Architectures 
ODA  and  Interchange  Format,  Part  7:  Raster  Graphics  Content  Architectures 
ODA  and  Interchange  Format,  Part  8:  Geometric  Graphics  Content  Architectures 


DADl 

Tiled  Raster  Graphics 

DAM  2.2 

Color 

DAD3 

Alternative  Representation 

DAD4 

Security 

DAM  3.2 

Streams 

DAD6 

Styles 

FDAM10 

ODA  External  References  and  Document  Fragments 

ODA  and  Interchange  Format,  Part  9:  Audio  Content  Architecture 
ODA  and  Interchange  Format,  Part  10:  Formal  Specifications 

AM  1  Formal  Specification  of  the  Document  Profile 

AM  2  Formal  Specification  of  the  Raster  Graphics  Content  Architectures 

AM  3  Formal  Specification  of  ODA  Character  Content  Architectures 

AM  4  Formal  Specification  of  ODA  Geometric  Graphics  Content  Architecture# 

AM  5  Formal  Specification  of  the  Defaulting  Mechanism  for  Defaultable 

Attributes 

ODA  Spreadsheet 

ODA  Identification  of  Document  Fragments 

Distributed  Office  Applications  Model  (DOAM),  Part  1:  General  Model 
Distributed  Office  Applications  Model  (DOAM),  Part  2:  Referenced  Date 
Document  Filing  and  Retrieval  (DFR),  Part  1:  Abstract  Service  Definition  and  Procedures 
Document  Filing  and  Retrieval  (DFR),  Part  2:  Protocol  Specification 

ODA  and  Interchange  Format  -  Testing  Methodology  and  Abstract  Cases  •  Implementation  Tasting 
StendHd  for  Exchange  of  Product  Model  Date  (STEP),  Part  11:  EXPRESS 

Intern atkinrl  Standardized  Profiles  POD  turn  -  ODA  -  Open  Document  Format:  Image  Applications  - 
Simple  Document  Structure  -  Raster  Graphics  Content  Architecture,  Part  1:  PCX)  112,  Document 
Applications  Profile,  August  1993  (balloting  ended  December  1993) 

Virtual  Ttrminal  Support  of  ODA 

Contributions  from  ISO/IEC  JTC1/SC18  Regarding  the  Progression  of  Work  on  Multimedia  and 
Hypermedia  Model/Framework 

Working  Draft  of  the  Technical  Report  on  Multimedia  and  Hypermedia:  Model  and  Framework 
Deposition  of  Comments  Report  and  Final  Work  Item  Definition  for  “Engagement  Scheduling  and 
Recording  Application  within  the  Distributed  Office  Applications  Model  (DOAM),”  October  1993 
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SC24  N  847  Initial  Draft  PREMO  (Preeantition  Environment  for  Multimadia  Objects). 

ITU-TS  T.400  Introduction  to  Docmneat  Architecture,  Traoafcr  and  Manipulation 

rrU-TS  T.4HVS  First  Extension  (January  1991)  to  the  T.410  Series  (1988)  of  Recommendations  Contained  in  the 

CQTT  Blue  Book,  Fascicle  VII.6 

ITU-TS  T.411  Open  Document  Architecture  (ODA)  and  Intercbanie  Format  -  Introduction  and  General  Principles 

(see  ISO  8613-1) 

ITU-TS  T.41 1/F  Annex  F  to  Recommendation  T.41 1 

ITU-TS  T.412  Open  Document  Architecture  (ODA)  and  Interchange  Format  -  Document  Structures  (aae  ISO  8613-2) 

ITU-TS  T.414  Open  Document  Archilectiae  (ODA)  and  Interchange  Format  -  Document  Profile  (aee  ISO  8613-4) 

ITU-TS  T.41S  Open  Document  Architecture  (ODA)  and  Interchange  Format  •  Open  Document  Interchange  Format 

(ODIF)  (see  ISO  8613-3) 

ITU-TS  T.416  Open  Document  Architecture  (ODA)  and  Interchange  Format  •  Character  Content  Architectures  (aee 

ISO  8613-6) 

ITU-TS  T.41 7  Open  Document  Architecture  (ODA)  and  Interchange  Format  -  Raster  Graphics  Cootent  Architecfes 

(see  ISO  8613-7) 

ITU-TS  T.418  Open  Document  Architecture  (ODA)  and  Interchange  Format  -  Geometric  Graphics  Content 

Architectures  (see  ISO  8613-8) 

ITU-TS  T.419  Document  Transfer  and  Manipulation  (DTAM)  -  Composite  Graphics  Content  Architectures 

ITU-TS  T.431  Document  Transfer  and  Manipulation  (DTAM)  •  Services  and  Protocols,  Introduction  and  General 

Principles 

ITU-TS  T.432  Document  Transfer  and  Manipulation  (DTAM)  -  Services  and  Protocols,  Service  Definition 

ITU-TS  T.433  Document  Transfer  and  Manipulation  (DTAM)  -  Services  and  Protocols,  Protocol  Specification 

ITU-TS  T.441  Document  Transfer  and  Manipulation  (DTAM)  -  Operational  Structure 

ITU-TS  T301  Rev  1  Document  Application  Profile  MM  for  the  Interchange  of  Formatted  Mixed  Mode  Documents  (Mixed 
Mode) 

ITU-TS  T.502  Rev  1  Document  Application  Profile  PM- 11  for  the  Interchange  of  Procesaable  Form  Documents  (Teletex 
Processable  Mode) 

rTU-TST.503  Document  Application  Profile  for  the  Interchange  of  Group  4  Facsimile  Documents 

ITU-TS  TJ04  Rev  1  Document  Application  Profile  for  Videotex  Interworking 

ITU-TS  T.505  Document  Application  Profile  PM -26  for  the  Interchange  of  Mixed  Content  Documents  in 

Processable  and  Format  Forms 

ITU-TS  T.521  Communication  Application  Profile  BTO  for  Document  Bulk  Transfer  Baaed  on  the  Session  Service 

(According  to  Rules  Defined  in  T.62  his) 

ITU-TS  TJ22  Communication  Application  Profile  BTl  for  Document  Bulk  Transfer 

ITU-TS  TJD  Rev  1  Communication  Application  Profile  DM-1  for  Videotex  Interworking 
ITU-TS  TJtl  Rev  1  Operational  Application  Profile  for  Videotex  Interworking 
ITU-TS  T.561  Terminal  Characteristics  for  Mixed  Mode  of  Operation  MM 

ITU-TS  T.562  Terminal  Characteristics  for  Teletex  Processing  Mode  nil 

ITU-TS  T363  Rev  1  Terminal  Characteristics  far  Group  4  Facsimile  Apparatus 
ITU-TS  T.564  Rev  1  Gateway  Characteristics  for  Videotex  Interworking 

Y.  PICTURE  DESCRIPTION  INFORMATION  EXCHANGE: 

ISO  8632-1  Computer  Graphics  Metafile  (COM):  Metafile  far  the  Storage  and  Transfer  of  Picture  Description 

Information,  Part  1:  Functional  Specification 
AMI  Audit  Trail  Metafile 

PD  AD  2  3D  Static  Picture  Capture  Metafile 

DAM  3  Parti:  Functional  Specification 

DAM4  Rules  for  Profiles 

ISO  8632-2  COM:  Metafile  for  the  Storage  sod  Transfer  of  Picture  Description  Information,  Part  2:  Character 

Encoding 

AM  1  rod  DAM  3 

ISO  8632-3  COM:  Metafile  for  the  Storage  and  Transfer  of  Picture  Description  Information,  Part  3:  Binary 

Encoding 

AM  1  and  DAM  3 

ISO  8632-4  COM:  Metafile  for  the  Storage  and  Transfer  of  Picture  Description  Information,  Part  4:  Clear  Text 

Encoding 

ISO  9281-1  Identification  of  Picture  Coding  Methods.  Part  1:  Identification.  1990 

ISO  9281-2  Identification  of  Picture  Coding  Methods,  Pvt  2:  Procedtue  for  Registration,  1990 

ISO  9282-1  Coded  Representation  of  Computer  Graphics  Images,  Part  1:  Encoding  Principles  for  Picture 

Representation  in  a  7-bit  or  8-bit  Environment,  1988 

ISO  9282-2  Coded  Representation  of  Computer  Graphics  Images,  Part  2:  Incremental  B«w<Hwg  of  Point  Lists  in 

a  7-bit  or  8-bit  Environment.  1992 
CD  10743  Standard  Music  Description  Language  (SMDL) 
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ISO/TEC  10918-1 

DIS  10918-2 
WD  10918-3 
ISO/IEC  11072 
ISO/IEC  11172-1 

ISO/IEC  11172-2 

ISO/IEC  11172-3 

CD  11172-4 

WD  11172-5 

ISO/IEC  11544 
ISO/IEC  11558 

DIS  12087-1 
DIS  12087-2 

DIS  12087-3 
CD  13522-1 

WD  13522-2 
WD  13522-3 

CD  13818-1 

CD  13818-2 

CD  13818-3 

WD  13818-4 


WD  13818-5 


WD  13818-8 


WD  13818-7 


SC21  N  5165 
SC21  N  6916 

SC21N6983 

SC29N363 

SC29N364 

SC29N365 

SC29N366 

SC29N367 

SC29N368 

rrU-TST.82 


Digital  Compression  and  Coding  of  Continuous-Tooe  Still  Images,  Part  1:  Requirements  and 
Guidelines,  1993 

Digital  Compression  and  Coding  of  Continuous-Tone  Still  Images,  Part  2:  Compliance  Testing 
Digital  Compression  and  Coding  of  Continuous-tone  Still  Images,  Part  3:  Extensions 
Computer  Graphics  •  Reference  Model  of  Computer  Graphics 

Coding  of  Moving  Pictures  and  Associated  Audio  for  Digital  Storage  Media  at  Up  to  about  1.5 
Mbit/s,  Put  1:  Systems,  1993 

Coding  of  Moving  Pictures  and  Associated  Audio  for  Digital  Storage  Media  at  Up  to  about  1.5 
Mbit/s,  Part  2:  Video,  1993 

Coding  of  Moving  Pictures  and  Associated  Audio  for  Digital  Storage  Media  at  Up  to  about  13 
Mbit/s,  Part  3:  Audio,  1993 

Coding  of  Moving  Pictures  and  Associated  Audio  for  Digital  Storage  Media  Up  to  About  13  Mbit/s, 
Part  4:  Conformance  Testing,  1993 

Coding  of  Moving  Pictures  and  Associated  Audio  for  Digital  Storage  Media  Up  to  About  13  Mbit/s, 

Part  5:  Technical  Report  on  Software  for  ISO/IEC  11172, 1993 

Coded  Representation  of  Bi-level  and  limited  Bits-per-pixel  Still  Pictures,  1993 

Data  Compression  for  Information  Interchange,  Adaptive  Coding  with  Embedded  Dictionary,  DCLZ 

Algorithm 

Image  Processing  and  Interchange  (IP!)  Standard,  Part  1,  Common  Architecture  for  Imaging  (CAI) 
Image  Processing  and  Interchange  (IPI)  Standard,  Part  2,  Programmer's  Imaging  Kernel  System 
(PDCS) 

Image  Processing  and  Interchange  (IPI)  Standard,  Part  3,  Image  Interchange  Facility  (OF) 

Coding  of  Multimedia  and  Hypermedia  Information,  Part  1:  MHEG  Objects  Representation  -  Base 
Notation  (ASN.l),  1993 

Coding  of  Multimedia  and  Hypermedia  Information,  Part  2:  Alternate  Natation  (SMSL),  1993 
Coding  of  Multimedia  and  Hypermedia  Information,  Part  3:  MHEG  Extensions  for  Scripting 
Language  Support,  1993 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio  Information,  Part  1:  Systems, 
SC29/WGU,  November  1993  [SC29  N  634]  (US  expected  March  1994,  IS  in  November  1994] 
Generic  Coding  of  Moving  Pictures  and  Associated  Audio  Information.  Part  2:  Video,  SC29/WG 11, 
November  1993  [SC29  N  634]  (US  expected  March  1994,  IS  in  November  1994] 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio  Information.  Part  3:  Audio,  SC29/WGU, 
November  1993  [SC29  N  635]  (DIS  expected  Match  1994,  IS  in  November  1994] 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio  Information,  Part  4:  Conformance 
Testing.  SC29/WGU,  November  1993  [SC29  N  636]  (CD  expected  November  1994,  DIS  in  Match 
1995,  IS  in  November  1995] 

Generic  Coding  of  Moving  Pictures  and  Associated  Andio  Information,  Part  5:  Technical  Report  on 
Software  for  ISO/IEC  13818,  SC29/WG11  (WD  expected  July  1994,  CD  in  November  1994,  DIS  in 
Match  1995,  IS  in  November  1995] 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio  Information.  Part  6:  System  Extensions, 
SC29/WG11  (WD  expected  November  1994,  CD  in  March  1995,  DIS  in  November  1995,  IS  in  July 
1996] 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio  Information,  Part  7:  Audio  Extensions, 
SC29/WGU  (WD  expected  November  1996,  CD  in  Match  1997,  CHS  in  July  1997,  IS  in  Match 
1998] 

FTAM  Constraint  Set  and  Document  Types  for  CGM 

Liaison  Statement  to  SC21/WG6  Concerning  the  Use  of  ASN.l  in  the  Image  Processing  and 

Interchange  Image  Interchange  Facility  (IPI-IIF)  Standard 

Liaiaon  Statement  to  SC24  Concerning  the  Use  of  ASN.l  hi  the  IPI/HF  Standards 

Image  Compression  Across  Muldpie  Components 

Lossy/Lossless  Coding  of  Bi-level  Images 

Compression  of  Up  to  5-D  Images 

Lossless  Compression  of  Continuous-Tone  Still  Pictures 

Very-low  Bitrate  Audio-Visual  Coding  (four  parts:  Systems,  Video,  Audio,  and  Conformance 
Testing),  1993 

Low-Bit-Rate  Audio  Coding,  1993 

Coded  Representation  of  Picture  and  Audio  Information- Progressive  Bi-level  Image  Compression 


Z.  STANDARD  GENERALIZED  MARKUP  LANGUAGE  (SGML): 


ISO  8879 

ISO  9069 
ISO/IEC  9070 
WOTR  9573-1 


Standard  Geasrsiind  Markup  Language  (SGML) 

AMI  Amendment  1 

SGML  Support  Facilities  -  SGML  Document  Intsrchange  Format  (SDIF) 

SGML  Support  Facilities  -  Registration  Procedures  for  Public  Text  Owner  Identifiers 
SGML  Support  Facilities -Techniques  for  Using  SGML,  Part  1:  SGML  Tutorial 
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WDTR  9573-2 
WDTR  9373-3 

WDTR  9573-4 

WDTR  9573-5 
WDTR  9573-6 
WDTR  9573-7 
WDTR  9573-8 
WDTR  9573-9 

WDTR  9573-10 

ISQflEC  TR  9573-11 

ISO/IEC  TR  9573-12 

ISCVIECTR  9573-13 

WDTR  9573-14 

WDTR  9573-15 

WDTR  9573-16 
ISOflEC  TR  10037 
ISCVIEC  10179 
DIS  10180 
ISCVIEC  10744 


SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Pvt  2:  Basic  Technique 

SGML  Supjxxt  Facilities  -  Techniques  for  Using  SGML,  Part  3:  Advanced  Techniques  -  Using  LINK 

and  CONCUR 

SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  4:  Advanced  Techniques  -  Using 
SHORTREF  to  Indicate  Markup 

SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  5:  Using  Noo-Latio  Alphabets 
SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  6:  Referencing  and  Synchronization 
SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  7:  Mathematics  and  Chemistry 
SGML  Support  Facilities -Techniques  for  Using  SGML,  PartS:  Tables 

SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  9:  Using  SGML  for  Computer  to 
Computer  Interchange 

SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  10:  Designing  Applications  for 
Database  Interfacing 

SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  11:  Application  at  ISO  Central 
Secretariat  for  International  Standards  and  Technical  Reports  to  TR  stains 

SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Pvt  12:  Public  Entity  Sets  for  General  and 
Publishing  Symbols 

SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Pvt  13:  Public  Entity  Sets  for  Mathematics 
mH  Sciftiwre 

SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  14:  Public  Entity  Sett  for  Latin  Baaed 
Alphabets 

SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  15:  Public  Entity  Seta  for  Non-Latin 
Based  Alphabets 

SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  16:  Public  Entity  Sett  for  Ideograms 
SGML  and  Text-Entry  Systems  -  Guidelines  for  SGML  Syntax-Directed  Editing  Systems 
Document  Style  Semantics  and  Specification  Language  (DSSSL) 

Standard  Page  Description  Language  (SPDL) 

Hypennedu/Time  -  based  Structuring  Language  (HyTime) 


A  A.  OTHER  APPLICATION  LAYER  STANDARDS: 


DP  9955 
D1S  10161-2 
pDISP  12065-1 

pDISP  12066-1 
pDISP  12066-2 


Methodology  and  Guidelines  for  the  Development  of  Application  Protocols  for  Banking 
Information  Interchange 

Information  and  Documentation  -  Open  Systems  Interconnection  -  Interlibrary  Loan  Application 
Protocol  Specification.  Part  2:  Protocol  Implementation  Conformance  Statement  Proforma 
International  Standardized  Profiles  ALD  In  -  Library  and  Documentation  -  Search  and  Retrieve.  Part 
1:  Specification  of  ACSE,  Presentation,  and  Session  Protocols  for  Use  by  Library  and 
Documentation,  August  1993 

International  Standardized  Profiles  ALD  2n  -  Library  and  Documentation  -  Interlibrary  Loan,  Part  1: 
Generic,  August  1993 

International  Standardized  Profiles  ALD  2n  -  Library  and  Documentation  -  Interlibrary  Loan,  Part  2: 
Using  Connection-Oriented  ACSE,  August  1993 
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DC.  MISCELLANEOUS  STANDARDS27 


A  Intogrulod  Sutvkwe  Digital  Nutwork  (ISDN):  Gunaral  Standard* 

B.  Electronic  Data  Interchange  (EDI) 

C.  Telematic  Services 

D.  Vocabulaiy  and  Repreeentationa 

E.  Coded  Character  Seta 

F.  Man-Machine  Language  (MML) 

Q.  Software  Development  and  Documentation 

H.  Information  Proeiaaaing  Equipment 


A.  INTEGRATED  SERVICES  DIGITAL  NETWORK  (ISDN):  GENERAL  STANDARDS2* 


ISOAEC  9574* 
ITU-TSL110 

rru-TSLin 

ITU-TS  LI  12  Rev  1 

rru-TS  LU3 
mJ-TSL114 
rru-TS  L120 
rru-TS  L121 
rru-TS  L122  Rev  1 
rru-TS  L144 
rru-TS  L150  Rev  t 
rru-TS  uoo 

ITU-TS  L210  Rev  1« 
ITU-TS  L2 II  Rev  U 
ITU-TS  L212* 
rru-TS  L220 
ITU-TS  L221  Rev  1 
rru-TS  L223.1 
rru-TS  L223.2 
rru-TS  L230 
rru-TS  U3i* 
rru-TS  I.231.9* 
rru-TS  L232* 
ITU-TS  L240* 
rru-TS  L241* 
ITU-TS  1.241. 7e 
rru-TS  L250* 
rru-TS  L231 
rru-TS  L252 
rru-TS  L233 
rru-TS  L2S3.1 
ITU-TS  L234 
rru-TS  L235 
rru-TS  L233J 
ITU-TS  L2S5A 
IIU-TSI.236 
rru-TS  1.254.2* 
rru-TS  L256.2b 
ITU-TS  1.236.2c 


Provision  of  the  OSI  Connection-Mode  Network  Service  by  Pocket  Mode  Terminal  Equipment 
Connected  to  an  ISDN 

General  Structure  of  the  I-Seriee  Recommendation! 

Reletionehip  with  Other  Recommendation!  Relevant  to  ISDN* 

Vocabulary  of  Team  for  ISDNi 

Vocabulary  of  Terms  for  Broadband  Aspects  of  ISDN! 

Vocabulary  of  Team  for  Uni  venal  Personal  Telecommunication 
Integrated  Service  Digital  Networks  (ISDNi) 

Broadband  Aspects  of  ISDNi 

Framework  for  Providing  Additional  Packet  Mode  Bearer  Service! 

Number  Identification  Supplementary  Services 

B-ISDN  Asyncfaroooui  Transfer  Mode  Functional  Characteristics 

Guidance  to  the  1.200  Series  of  Recommendation! 

Principles  of  Telecommunications  Services  Supported  by  an  ISDN 
B-ISDN  Service  Aspects 
Teleservices  Supported  by  an  ISDN 

Common  Dynamic  Description  of  Basic  Telaoommuninatinn  Services 
Common  Specific  Characteristics  of  Services 

ISDN  Frame  Mode  Bearer  services  (FMBS)  -  ISDN  Frame  Relaying  Da— r  Services 
ISDN  Frame  Mode  Bearer  services  (FMBS)  -  ISDN  Frame  Switching  Dearer  Service 
Definition  of  Bearer  Service  Categories 
Circuit-Mode  Bearer  Service  Categories 

Circuit  mode  64  kbit/s  S  kHz  structured  multi -use  bearer  service  category 

Packet  Mode  Beam  Service  Categories 

Definition  of  Teleservices 

Teleservices  Supported  by  an  ISDN 

Telephony  7  kHz 

Definition  of  Supplementary  Services 
Number  Identification  Supplementary  Services 
Call  Offering  Supplementary  Services 
Call  Completion  Supplementary  Services 
Call  Waiting  (CW)  Supplementary  Service 
Multiparty  Supplementary  Services 
Community  of  Interest  Supplementary  Services 

Multi-level  Precedence  and  Preemption  Service  (MLPP)  -  Description  Preterence  Service 
Priority  Service 

Changing  Supplementary  Services 

Advice  of  Charge:  Charging  Information  at  Call  Set-Up  Time 
Advice  of  Charge:  Charging  Information  During  Call 
Advice  of  Charge:  Charging  Information  at  End  of  the  CaU 


27  The  symbol  e  is  ased  throughout  this  appendix  to  identify  thorn  standards  included  in  the  Saplambar  1993  NOSIF 
Stnugy. 

2*  A  list  of  ITU-TS  (formally  C&TT)  1992  Recommendations  on  ISDN  is  provided  in  Appendix  B,  Section  HB. 
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ITU-TS  L257 
ITU-TS  L320 
ITU-TS  L32I 
ITU-TS  L32S  Rev  1 
ITU-TS  1.327  Rev  1 
ITU-TS  1.333  Rev  1 
ITU-TS  L340 
ITU-TS  L410 
ITU-TS  1.411  Rev  1 

m)-TSL412 
ITU-TS  L4I3  Rev  1 
ITU-TS  1.420 
ITU-TS  L421 

rru-TSLS<o 
ITU-TS  L601 
ITU-TS  L602 
ITU-TS  L603 
ITU-TS  L604 
ITU-TS  L605 
ITU-TS  L610  Rev  1 


Additional  Infonnation  Transfer  Supplementary  Service* 

ISDN  Protocol  Reference  Model 

B-ISDN  Protocol  Reference  Model  and  Its  Application 

Reference  Configurations  for  ISDN  Connection  Types 

B-ISDN  Functional  Architecture 

Terminal  Selection  in  ISDN 

ISDN  Connection  Types 

General  Aspects  and  Principles  Relating  to  Recommendations  on  ISDN  User-Network  Interfaces 

ISDN  User-Network  Interfaces  -  Reference  Configurations 

ISDN  User-Network  Interfaces  -  Interface  Structures  and  Access  Capabilities 

B-ISDN  User  Network  Interface 

Basic  User-Network  Interface  (ISDN) 

Primary  Rale  User-Network  Interface  (ISDN) 

Requirements  to  be  Met  in  Providing  the  Telex  Service  Within  the  ISDN 
General  Maintenance  Principles  of  ISDN  Subscriber  Access  and  Subscriber  Installation 
Application  of  Maintenance  Principles  to  ISDN  Subscriber  Installation 
Application  of  Maintenance  Principles  to  ISDN  Buie  Accesses 
Application  of  Maintenance  Principles  to  ISDN  Primary  Rate  Accesses 
Application  of  Maintenance  Principles  to  Static  Multiplexed  ISDN  Basic  Accesses 
DAM  Principles  of  the  B-ISDN  Access 


B.  ELECTRONIC  DATA  INTERCHANGE  (EDI): 


ISO  9735 


SC21  N3SS5 
SC21  N  5635 

SC21  N  6224 
SC21  N  7184 


Electronic  Data  Interchange  for  Administration,  Commerce  and  Transport  (EDIT ACT)  -  Application 
Level  Syntax  Rules 

AMI  Amendment  1 

UN/EDiF  ACT  Information  Pack 

Report  of  the  Special  Working  Group  on  a  Conceptual  Model  for  Electronic  Data  Interchange 
Standards  and  Services  (SWG-EDI) 

Proposed  EDIFACT/FT  AM  Document  Type 
Liaison  Statement  to  J7C1/WG3  on  EDI 


C.  TELEMATIC  SERVICES: 


DP  9071-1.2  Text  and  Office  Systems  •  Basic  and  Optional  Requirements.  Part  1:  Facsimile  Equipment 

DP  9071-2.2  Text  and  Office  Systems  •  Basic  and  Optional  Requirements,  Part  2:  Text  Communications 

Terminals 


ITU-TS  F.  30  Rev  1 
ITU-TS  F.  63  Rev  1 
ITU-TS  F.  69  Rev  1 
ITU-TS  F.  72  Rev  1 
ITU-TS  F.  140  Rev  1 
ITU-TS  F.  160  Rev  1 
ITU-TS  F.  180  Rev  1 

ITU-TS  F.  182  Rev  1 

ITU-TS  F.  184  Rev  1 


ITU-TS  F.  200 
ITU-TS  F.  20tVC 
ITU-TS  F.  201  Rev  1 
ITU-TS  F.  220  Rev  1 
ITU-TS  F.  300  Rev  1 
ITU-TS  F.  551 

ITU-TS  F.  581 
ITU-TS  F.  600  Rev  1 
I1U-TSF.710 
ITU-TS  F.  850 
ITU-TS  F.  901 
ITU-TS  T.  0 
ITU  -TS  T.  4  Rev  3 
ITU-TS  T.  5 


Uae  of  Various  Sequences  of  Combinations  for  Special  Purposes 
Additional  Fatalities  in  the  International  Telex  Service 
Plan  for  Telex  Destination  Codes 

International  Telex  Store  and  Forward  -  General  Principles  and  Operational  Aspects 

Point-to-Multipoinl  Telecommunication  Service  Via  Satellite 

General  Operational  Provisions  for  the  International  Public  Facsimile  Services 

General  Operational  Provisions  for  the  International  Public  Facsimile  Service  Between  Subscribers’ 

Stations  (Telefax) 

Operational  Provisions  for  the  International  Public  Facsimile  Service  Between  Subscriber  Stations 
with  Group  3  Facsimile  Machines  (Telefax  3) 

Operational  Provisions  for  the  International  Public  Facsimile  Service  Between  Subscriber  Stations 
with  Group  4  Facsimile  Machines  (Telefax  4) 

Telefax  Service 

Telefax  Service,  Annex  C:  Mixed  Mode  of  Operation 
Internetworking  Between  the  Teletex  Service  and  the  Telex  Service 
Service  requirements  Unique  to  the  Processsble  Mode  Number  One  (PM1) 

Videotext  Service 

Service  Recommendation  for  Telematic  File  Transfer  Within  Telefax  3,  Telefax  4,  Teletex  and 
Message  Handling  Services 

Guidelines  for  Programming  Communication  Interfaces  Definition  (Service  Recommendation) 

Service  and  Operational  Principles  for  Public  Data  Transmission  Services 

General  Principles  for  Audiographic  Conference  Services 

Principles  of  Universal  Personal  Telecommunication 

Usability  Evaluation  of  Telecommunication  Services 

Classification  of  Facsimile  Apparatus  for  Document  Transmission  over  the  Public  Networks 
Standardization  of  Group  3  Facsimile  Apparatus  for  Document  Transmission 
Geoeral  Aspects  of  Group  4  Facsimile  Apparatus 
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1TU-TST.6  Facshnik  Coding  Schemes  aad  Coding  Control  Puoctioas  far  Group  4  Facshnik  Apprtns 

ITU-TS  T.  22  Stendaidixed  Ted  Charts  for  Document  Facsimile  Transmissions 

ITU-TS  T.  30  Rev  3  Procedures  for  Document  Facshnik  Transmission  in  the  General  Switched  Telephone  Natwodt 

ITU-TS  T.  35  Procedure  for  the  Allocation  of  Defined  Codes  for  Non-Standard  Facilities 

ITU-TS  T.  50  International  Alphabet  No.  5 

ITU-TS  T.  51  Coded  Character  Sets  for  Telematic  Services 

ITU-TS  T.  52  Non-Latin  Coded  Character  Sets  for  Telematic  Services 

ITU-TS  T.  60  Rev  1  Terminal  Equipment  for  Use  in  the  Teletex  Service 

IIU-TS  T.  61  Rev  1  Character  Repertoire  and  Coded  Character  Sets  for  the  International  Tristan  Service 

ITU-TS  T.  62  Rev  1  Control  Procedures  for  Teletex  and  Group  4  Facsimile  Services 

ITU-TS  T.  62  bk  Rev  1  Control  Procedures  for  Teletex  and  Group  4  Facsimile  Services  Baaed  on  Recommendations 
X.213/X.225 

ITU-TS  T.  63  Rev  1  Provision  for  Verification  of  Teletex  Terminal  Compliance 

ITU-TS  T.  64  Rev  1  Conformance  testing  procedures  for  the  teletex  Recommendations 

ITU-TS  T.  70  Rev  1*  Network-Independent  Buie  Transport  Service  for  the  Telematic  Services 

rrU-TS  T.  71  LAPS  Extended  for  Half-Duplex  Physical  Level  Facility 

ITU-TS  T.  72  Terminal  Capabilities  for  Mixed  Mode  of  Operation 

ITU-TS  T.  73  Document  Interchange  Protocol  for  the  Telematic  Services 

ITU-TS  T.  82  Coded  Representation  of  Picture  and  Audio  Information-Progressive  Bi-levri  Image  Compression 

mJ-TS  T.  90  Teletex  Requirements  for  Internetworking  with  the  Telex  Service 

IIU-TS  T.  91  Teletex  Requirements  for  Real-Time  Internetworking  with  the  Telex  Service  in  a  Packet-Switching 

Network  Environment 

IIU-TS  T.  101  Rev  1  International  Interworking  for  Videotex  Services 

IIU-TS  T.  102  Protocols  for  Syntax-Based  Videotex  Using  ISDN  Circuit  Mode 

ITU-TS  T.  103  Protocols  for  Syntax-Based  Videotex  Using  ISDN  Packet  Mode 

ITU-TS  T.  104  Packet  Mode  Access  for  Syntax-Based  Videotex  Via  PSTN 

ITU-TS  T.  IQS  Syntax-Based  Videotex  Application  Layer  Protocol 

TTU-TS  T.  106  Framework  for  Videotex  Terminal  Protocols 

IIU-TS  T.  122  Multipoint  Communications  Service 

TTU-TS  T.  123  Protocol  Stacks  For  Audiographic  And  Audiovisual  Teleconference  Applications 

IIU-TS  T.  330  Telematic  Access  to  Interpersonal  Messaging  System 


D.  VOCABULARY  AND  REPRESENTATIONS: 


ISO  2382-1  Vocabulary,  Part  1:  Fundamental  Terms 

ISO  2382-2  Vocabulary,  Part  2:  Arithmetic  and  Logic  Operations 

ISO  2382-3  Vocabulary.  Part  3:  Equipment  Technology 

ISO  2382-4  Vocabulary,  Part  4:  Organization  of  Data 

ISO  2382-5  Vocabulary,  Part  S:  Representation  of  Data 

ISO  2382-6  Vocabulary,  Put  6:  Preparation  and  Handling  of  Data 

ISQflEC  2382-7  Vocabulary,  Part  7:  Computer  Programming 

ISO  2382-8  Vocabulary,  Part  8:  Control,  Integrity,  and  Security 

ISO  2382-9  Vocabulary,  Part  9:  Data  Communications 

CD  2382-9.2  Vocabulary,  Part  9:  Data  Communications,  Edition  2 

ISO  2382-10  Vocabulary,  Part  10:  Operating  Techniques  and  Facilities 

ISO  2382-11  Vocabulary,  Part  11:  Processing  Units 

ISO  2382-12  Vocabulary,  Part  12:  Peripheral  Equipment 

ISO  2382-13  Vocabulary,  Part  13:  Computer  Graphic* 

ISO  2382-14  Vocabulary,  Part  14:  Reliability,  Maintenance,  and  Availability 

ISO  2382-15  Vocabulary,  Part  15:  Programming  Languages 

ISO  2382-16  Vocabulary,  Part  16:  Information  Theory 

US  2382-17  Vocabulary,  Part  17:  Databases 

ISO  2382-18  Vocabulary,  Part  18:  Distributed  Data  Processing 

ISO  2382-19  Vocabulary,  Part  19:  Analog  Computing 

ISQAEC  2382-20  Vocabulary,  Part  20:  System  Development 

ISO  2382-21  Vocabulary,  Part  21:  Interfaces  Between  Process  Computer  Systems  and  Technical  Processes 

ISO  2382-22  Vocabulary,  Part  22:  Calculators 

CD  2382-23  Vocabulary,  Part  23:  Text  Processing 

ISQfflEC  2382-25  Vocabulary,  Part  25:  Local  Area  Networks 

DIS  2382-26  Vocabulary,  Part  26:  OSI  Architecture 

ISO  2955  Representation  of  SI  and  Other  Units  in  Systems  with  limited  Character  Sett 

ISO  3166  Codes  for  the  Representation  of  Names  of  Countries 

ISO  3307  Representations  of  Time  of  the  Day 
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ISO  3534 
ISO  4031 
ISO  6093 
ISO  6523 

ISO  6548 

ISO  6709 
DIR  7352 
US  7826-1 

DIS  7826-2 

ISO  8211 
IMS  8211.2 
ISO  8601 
ISO  8790 
ISQflEC  9282-1 

ISCVIEC  9282-2 
ISOAECTR9S44 
TR  9789 
WD  11179-13 

WD  11179-23 

US  11179-3 
1»S  11179-4 
CD  11179-53 
CD  11179-6 
CD  11714 
ISOAECIR  12382 
CD  13522 
SC21  N  5394 


Statistics  •  Vocabulary  and  Symbols 

Infonnation  Interchange  -  Representation  of  Local  Time  Differentials 
Representation  of  Numeric  Values  in  Character  Strings  for  Information  Exchange 
Data  Interchange  -  Structure  for  the  Identification  of  Organizations 
DAM1  Guidance  on  the  Use  of  ISO  6523 


Data  processing.  Description  of  Interface  Between  Process  Computing  System  and  Technical 
Processes,  1984 

Standard  Representation  of  Latitude,  Longitude  and  Altitude  for  Geographic  Point  Locations 
Guidelines  for  Grouping  of  Data  Elements  in  the  Context  of  Data  Interchange  (being  withdrawn) 
Representation  of  Data  Elements,  Part  1:  Identification  of  Coding  Schemes  for  Data  Elements 
(Types),  November  1993 

Representation  of  Data  Elements,  Part  2:  Registration  of  Coding  Schemes  for  Data  Elements 
(Types),  November  1993 

Specification  for  a  Data  Descriptive  File  for  Information  Interchange 
Specification  for  a  Data  Descriptive  File  for  Information  Interchange,  Edition  2 
Representation  of  Dates  and  Tunes 

Computer  System  Configuration  Diagram  Symbols  and  Conventions 

Coded  Representation  of  Pictures,  Part  1:  Encoding  Principles  for  Picture  Representation  in  a  7-  or 
8-Bit  Environment 

Coded  Representation  of  Pictures,  Part  2:  Encoding  Principles  for  Photographic  Images 
Computer-Assisted  Publishing  -  Vocabulary 

Guidelines  for  Data  Interchange  •  Coding  Methods  and  Principles,  November  1993 
Coordination  of  Data  Elements,  Part  1:  Framework  for  the  Generation  and  Standardization  of  Data 
Elements.  November  1993 


Coordination  of  Data  Elements,  Part  2:  Classification  of  Concepts  for  the  Identification  of 
Domains,  November  1993 


Coordination  of  Data  Elements,  Part  3:  Data  Element  Attributes.  November  1993 
Coordination  of  Data  Elements,  Part  4:  Definition  of  Data  Elements,  Janaury  1994 
Coordination  of  Data  Elements,  Part  5:  Naming  Principles  for  Data  Elements,  Janaury  1994 
Coordination  of  Data  Elements,  Part  6:  Representation  of  Data  Elements  (Types),  November  1993 
General  Principles  for  the  Creation  of  Symbols  for  Use  in  Technical  Documentation  of  Products 
Permuted  Index  of  the  Vocabulary  of  Information  Technology 
Coded  Representation  of  Multimedia  and  Hypermedia  Information  Objects 
Collections  of  Definitions  of  OSI  Vocabulary 


E.  CODED  CHARACTER  SETS: 


ISO  646 
ISO  2022 
ISO  4873 
ISO  6429 
ISO  6936 

ISO  6937-1 
ISO  6937-2 


CHS  6937-23 

DIS  6937-3 
IXS  6937-7 
DIS  6937-8 
ISOABC7350 
ISO  8859-1 
ISO  8859-2 
ISO  8859-3 
ISO  8859-4 
ISOflEC  8859-5 
ISO  8859-6 
ISO  8859-7 
ISO  8859-8 
ISOdEC  1859-9 
ISOflEC  8859-10 


ISO  7-Bit  Coded  Character  Set  for  Information  Exchange 

ISO  7-Bit  and  8-Bit  Coded  Character  Sets  -  Code  Extension  Techniques 

8-Bit  Code  for  Information  Interchange  -  Structure  and  Rules  for  Implementation 

ISO  7-Bit  and  8-Bit  Coded  Character  Sets  -  Control  Functions  for  Coded  Character  Sets 

Conversion  Between  the  Two  Coded  Character  Sets  of  ISO  646  and  ISO  6937-2  and  the  CdTT 

International  Telegraph  Alphabet  No.  2  (ITA2),  Edition  2 

Coded  Character  Sets  for  Text  Communication,  Part  1:  General  Introduction 

Coded  Character  Sets  for  Text  Communication,  Part  2:  Latin  Alphabetic  and  Non- Alphabetic 

Graphic  Characters 

ADI  Addendum  1 

Coded  Character  Sets  for  Text  Communication,  Part  2:  Latin  Alphabetic  and  Non-Alphabetic 
Graphic  Characters,  Edition  2 

Coded  Character  Sets  for  Text  Communication,  Part  3:  Control  Functions  for  Page-Image  Format 
Coded  Character  Seta  for  Text  Communication,  Part  7:  Greek  Graphic  Characters 
Coded  Character  Sets  for  Text  Communication,  Part  8:  Cyrillic  Graphic  Characters 
Registration  of  Graphic  Character  Subrepertoires  ' 

8-Bit  Single-Byte  Coded  Graphic  Character  Sets,  Part  1:  Latin  Alphabet  No.  1 

8-Bit  Single-Byte  Coded  Graphic  Character  Seta,  Part  2:  Latin  Alphabet  No.  2 

8-Bit  Single-Byte  Coded  Graphic  Character  Seta,  Part  3:  Latin  Alphabet  No.  3 

8-Bit  Single-Byte  Coded  Graphic  Character  Seta,  Part  4:  Latin  Alphabet  No.  4 

8-Bit  Single-Byte  Coded  Graphic  Character  Sets,  Part  5:  Latin/Cyrillic  Alphabet 

8-Bit  Single-Byte  Coded  Graphic  Character  Seta,  Part  6:  Latin/Arabic  Alphabet 

8-Bit  Single-Byte  Coded  Graphic  Character  Sett,  Part  7:  Latin/Greek  Alphabet 

8-Bit  Single-Byte  Coded  Graphic  Character  Seta,  Part  8:  Latin/Hebrew  Alphabet 

8-Bit  Single-Byte  Coded  Graphic  Character  Seta,  Part  9:  Latin  Alphabet  No.  5 

Information  Processing  •  8-Bit  Single-Byte  Coded  Graphic  Character  Seta,  Part  10:  Latin/ 

Alphabet 
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ISQflEC  9541-1 

ISO/IEC  9541-2 
NS  9541-3 
NS  9541-4 
ns  9541-5 
ns  9541-6 

DP  9541-7 
ISO/IEC  10036 
ISO/IEC  10646 
ISO/IR  11065 
ISO  11103 
ISO  11104 
SC21  N  8260 


Foot  and  Character  Informatics  Exchange,  Part  1:  Iotrodnctton 
Cor  1  Technical  Corrigenthmi  1 

Foot  aad  Character  Information  Exchange,  Pwt  2:  Registration  and  Naottag  Procedures 

Font  and  Character  Information  Exchange,  Part  3:  Glyph  Shape  Rrpraeantatioo 

Font  and  Character  Information  Exchange,  Part  4:  Character  CoUectfcma 

Font  and  Character  Information  Exchange,  Part  5:  Font  Attribute  and  Character  Model 

Font  and  Character  Information  Exchange,  Part  6:  Font  and  Character  Attribute  Subecta  aad 

Application 

Font  and  Character  Information  Exchange,  Part  7:  Foot  Interchange  Format 
Procedure  for  Registration  of  Glyph  and  Glyph  Collection  Ideotifien,  1993 
Multiple  Octet  Coded  Character  Set 
Industrial  Automation  Glossary,  1992 

Space  Data  and  Information  Transfer  Systems  -  Radio  Metric  and  Orbit  Data,  1991 

Space  Date  and  Information  Transfer  Systems  -  Time  Code  Formats,  1991 

liaison  to  SC21  on  the  Character,  Graphic  Symbol  and  Glyph,  SC18/WG8,  October  1993 


F.  MAN-MACHINE  LANGUAGE  (MML)t 


mi-Tszjoi 

1TU-TS2L302 
rru-Tszjii 
ITU-TS  Z.312 
nru-Tszjw 
ITU-TS  Z3 15 
ITU-TS  Z316 
ITU-TS  Z3 17 
ITU-TS  2L321 
ITU-TS  Z322 
ITU-TS  2L323 
ITU-TS  Z331 
nU-TSZJ32 
ITU-TS  Z333 
IIU-TS  Z341 
ITU-TS  Z351 
IIU-TS  Z352 


Introduction  to  the  CCTTT  Man-Machine  Language  (MML) 

The  Mete-Language  for  Describing  MML  Syntax  and  Dialogue  Procedures 
Introduction  to  Syntax  and  Dialogue  Procedures  (MML) 

Basic  Format  Layout  (MML) 

The  Character  Set  and  Basic  Elements  (MML) 

Input  (Command)  language  Syntax  Specification  (MML) 

Output  Language  Syntax  Specification  (MML) 

Man-Machine  Dialogue  Procedures  (MML) 

Introduction  to  the  Extended  MML  for  Visual  Display  Terminals 
Capabilities  of  Visual  Display  Terminals 
Man-Machine  Interaction 

Introduction  to  the  Specification  of  the  Man-Machine  Interface 

Methodology  for  die  Specification  of  the  Man-Machine  Interface  -  General  Working  Procedures 
Methodology  for  the  Specification  of  the  Man-Machine  Interface  -  Tools  and  Methods 
Glossary  of  Terms  (MML) 

Data-oriented  Human-Machine  Interface  Specification  Techniques.  Part  1:  Introduction 
Data-oriented  Human-Machine  Interface  Specification  Techniques,  Part  2:  Scope,  Approach  and 
Reference  Model 


G.  SOFTWARE  DEVELOPMENT  AND  DOCUMENTATION: 


ISO/TR  12S6 
ISCVIEC  1538 
ISO  1539 
DIS  1539.2 
ISO  1989 

ISO  6160 
ISO  6373 
ISCVIEC  6522 
ISO  6592 
ISO  7185 
ISO  8485 
ISO  8631 
ISO  8652 
ISO  9000 
ISO  9000-3 

ISO  9001 

ISO  9002 
ISO  9003 
ISO  9004 
ISO  9004-2 
ISCVIEC  9126 


Manufacturing  Automation  Programming  Language  Environment  Architecture  (MAPLE),  1993 
Programming  Languages  -  ALGOL  60 
Programming  Languages  -  FORTRAN 
1  Programming  Languages  -  FORTRAN  Extended 
Programming  Languages  -  COBOL 

AM  1  Amendment  1:  Intrinsic  Function  Module 

Programming  Languages  •  PL/1 
Programming  Languages  -  BASIC 
Programming  Languages  •  PL/1  General  Purpose  Subset 
Guidelines  for  the  Documentation  of  Computer-Baaed  Application  Systems 
Programming  Languages  -  Pascal 
Programming  Languages  -  APL 

Information  Technology  -  Program  Constructs  and  Conventions  for  Their  Representation.  1989 
Programming  languages  -  Ada 

Quality  Management  and  Quality  Assurance  Standards  -  Guidelines  for  Selection  and  Use,  1987 
Quality  Management  and  Quality  Assurance  Standards,  Part  3:  Guidelines  for  the  Application  of  ISO 
9001  to  the  Development,  Supply,  and  Maintenance  of  Software,  1991 

Quality  Systems  •  Model  for  Quality  Assurance  in  Design/Developmeut,  Production.  Installation 
and  Servicing,  1987 

Quality  Systems  -  Model  for  Quality  Assurance  in  Production  and  Installation,  1987 

Quality  Systems  -  Model  for  Quality  Assurance  in  Final  Inspection  and  Test.  1987 

Quality  Management  and  Quality  System  Ehsnents  •  Guidelines,  1987 

Quality  Management  and  Quality  System  Elements,  Part  2:  Guidelines  for  Services,  1991 

Information  technology.  Software  Product  Evaluation,  Quality  Characteristics  and  Guidelines  for 

Their  Use 
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UNCLASSIFIED 


UNCLASSIFIED 


ISO  9127 

ISO/IEC  TR  9294 
ISO  9496 
ISO/TR  9547 

ISO  9899 
ISO/IEC  TR  10034 
ISO/IEC  TR  10176 
DIR  10182 
ISO/IEC  10206 
ISO/IEC  10279 
CD  10967-1 

WD  10967-2 

ISO/IEC  11404 
ISO/IEC  11756 
ISO/IEC  12119 
DIS  13719-1 
IMS  13719-2 

CHS  13719-3 

SC21  N  6820 
SC21  N  8103  Rot. 
ITII-TS  2L200  Rot  1 
rru-Ts  z.400 


Information  processing  systems.  User  Documentetion  end  Cover  Information  for  Consumer 
Softwsre  Packages 

Guidelines  for  the  Management  of  Software  Documentation.  Technical  Report  Type  3 
Programming  Languages  •  CCTTT  High  Level  Language  (CHILL) 

Programming  Language  Processors  •  Test  Methods  -  Guidelines  for  Their  Development  and 
Acceptability 

Programming  Languages  -  C 

Guidelines  for  the  Preparation  of  Conformity  Clauses  in  Programming  language  Standards 

Guidelines  for  the  Preparation  of  Programming  Language  Standards 

Binding  Techniques  for  Programming  languages 

Programming  Languages  Extended  Pascal 

Programming  Languages  -  Pull  BASIC 

Programming  Languages,  Their  Environments  and  Systems  Software  Interfaces  -  Language 
Compatible  Arithmetic,  Part  1:  Integer  and  Floating  Point  Arithmetic 

Programming  Languages,  Their  Environments  and  Systems  Software  Interfaces  -  Language 
Compatible  Arithmetic,  Part  2:  Complex  Arithmetic  and  Mathematical  Procedures 
Programming  languages  -  Common  I anguage-Indepeudsnt  Data  Types  (CUD) 

Programming  Languages,  MUMPS 

Software  Packages:  Quality  Requirements  and  Testing 

Portable  Tools  Environment  (PCTE),  Part  1:  Abstract  Specification  (ECMA-149) 

Portable  Common  Tools  Environment  (PCTE),  Part  2:  C  Programming  Language  Binding  to  PCTE 
(ECMA-158) 

Portable  Common  Tools  Environment  (PCTE),  Part  3:  Ada  Programming  Language  Binding 
(ECMA-162) 

liaison  Statement  for  SC22/WGU,  Binding  Techniques,  to  SC21/WG6  RPC  Rapporteur  Group 
Request  from  SC21  to  iTCl  Concerning  the  “Fast  Tracking''  of  the  PCTE  Document,  June  1993 
mi-TS  High  Leml  Language  (CHILL) 

Structure  and  Format  of  Quality  Manuals  for  Telecommunication  Software 


H.  INFORMATION  PROCESSING  EQUIPMENT: 


ISO  8884 
ISO  9171-1 

ISO  9171-2 


Keyboards  for  Multiple  Latin-Afehabet  Languages  -  Layout  and  Operation  Using  Four  Levels 
130  mm  Optical  Did:  Cartridge,  Write  Once,  for  Information  Interchange,  Part  1:  Unrecorded 
Optical  Disk  Cartridge 

130  mm  Optical  Disk  Cartridge,  Write  Once,  for  Information  Interchange,  Part  2:  Recording 
Format 


ISO  9660 
DIS  9995-1 

MS  9995-2 
MS  9995-3 

MS  9995-4 

MS  9995-5 
MS  9995-6 
MS  9995-7 
MS  9995-8 

DP  10033 

ISO  10149 
MS  10222 
MS  10994 

ISO/IEC  11319 
MS  11321 


Volume  and  File  Structure  of  CD-ROM  for  Information  Exchange 

Keyboard  Layouts  for  Text  and  Office  Systems,  Part  1:  General  Principles  Governing  Keyboard 
Layouts 

Keyboard  Layouts  for  Text  and  Office  Systems,  Part  2:  Alphanumeric  Section 

Keyboard  Layouts  for  Text  and  Office  Systems,  Part  3:  Common  Secondary  Layout  of  Alphanumeric 

Zone  of  Alphanumeric  Section 

Keyboard  Layouts  for  Text  and  Office  Systems,  Part  4:  Principles  Governing  the  Placement  of 
Characters  and  Symbols  on  Keys 

Keyboard  Layouts  for  Text  and  Office  Systems,  Part  5:  Editing  Secdoo 

Keyboard  Layouts  for  Text  and  Office  Systems,  Pwt  6:  Functional  Section 

Keyboard  Layouts  for  Text  and  Office  Systems,  Part  7:  Symbols  Used  to  Represent  Functions 

Keyboard  Layouts  for  Text  sod  Office  Systems,  Part  8:  Allocation  of  Letters  to  the  Keys  of  a 

Numeric  Keyboard 

Recording  of  Documents  Conforming  to  ISO  8613  on  Flexible  Dirk  Cartridges  Conforming  to  ISO 
9293 

Date  Interchange  on  Read-Only  120>mm  Optical  Data  Disks  (CD-ROM) 

Enhanced  Small  Device  Interface 

Date  Interchange  on  90  mm  Flexible  Dirk  Cartridges  Using  MFM  Recording  at  31,831  FTPRAD  on 
80  Trades  on  Each  Side 

8  nun  Wide  Magnetic  Tape  Cartridge  for  Information  Interchange  -  Helical  Scan  Recording,  1993 
3,81  mm  Wide  Magnetic  Tape  Cartridge  for  Information  Interchange  •  Helical  Scan  Recording  - 
Data/Data  Format,  1993 
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APPENDIX  E 

NUMERICAL  LISTING  OF  ISO  STANDARDS  AND 
CCITT  RECOMMENDATIONS  RELEVANT  TO  CCISs 


I.  »0  Standards 

II.  CCITT  Standards 


UNCLASSIFIED 


UNCLASSIFIED 


NUMERICAL  LISTING  OF  ISO/IEC  STANDARDS 
AND  ITU-TS  (FORMERLY  CCITT) 
RECOMMENDATIONS  RELEVANT  TO  INFORMATION  SYSTEMS1 


L  ISO/IEC  STANDARDS 


ISO  646 
IBCS47 
IBC/IR907 
ISO  1155 

iso/trum 
ISO  1177 

ISQ/IBC  1531 
ISO  1539 
US  1539.2 
ISO  1745 

ISO  1969 
ISO  1969  AM  1 
ISO  2022 

ISO  2110*3 

ISO  2110  AMI 

ISO  2111 

ISO  2375 
ISO  2382-1 
ISO  2382-2 
ISO  2382-3 
ISO  2382-4 
ISO  2382-5 
ISO  2382-6 

ISOrtBC  2382-7 
ISO  2382-8 
ISO  2382-9 
CD  23*2-9.2 
ISO  2382-10 
ISO  2382-11 
ISO  2382-12 
ISO  2382-13 
ISO  2382-14 


Informatioo  Processing  -  ISO  7-Bit  Coded  Cbaacter  Set  foe  Information  Exchange,  Edition  3. 1991 
Characteristics  of  LAN*,  1988 

Local  Ana  Networks  CSMA/CD  10  Mbit/a  Baaahand  Flaming  and  Installation  Guide,  1989 
Information  Processing  -  Uae  of  Longitudinal  Parity  to  Detect  Error*  in  Information  Meaaagao, 
Edition  2,  1978 

Manufacturing  Automation  Programming  Language  Environment  Architecture  (MAPLE),  1993 
Information  Proceaaing  •  Character  Structure  for  Start/Stop  and  Syncfaronooa  Character  Oriented 
Transmission,  Edition  2,  1985 

Infosmation  Technology  -  Programming  Language*  -  ALGOL  60, 1984 
Programming  Language*  -  FORTRAN,  Edition  2, 1991 
Prograaming  Lugnagss  •  FORTRAN  Extended,  1991 

Information  Proceaaing  -  Baric  Mode  Control  Procedure*  for  Data  Communication  Systems, 
February  197S 

Programming  Language*  -  CCBOL  (Endorsement  of  ANSI  Standmd  X3  J3-1976),  Edition  2, 1985 
Amendment  1,  Intrineic  Punction  Module,  1992 

Information  Processing  -  ISO  7 -Bit  and  8-Bit  Coded  flteracaer  Seta  -  Code  Extension  Techniques, 
Edition  3.  May  1986 


Infoanatkm  Technology  -  Date  Communication  -  25 -Pin  DIE/DCE  Interface  Connector  and  Contact 
Number  Aerigmeenu,  Edition  3, 10  April  1989 

Amendment  1,  Interface  Connector  and  Contact  Number  Assignments  for  e  DTE/DCE  for  Date 
Signalling  Rate*  Above  20  kbit/s,  April  1991 

Date  Communication  -  Basic  Mode  Control  Procedures  -  Code  Independent  Information  Transfer, 
Edition  2,  February  1985 

Data  Processing  -  Procedural  for  the  Registration  of  Escape  Sequences.  Edition  3,  November  1985 
Data  Processing  -  Vocabulary,  Pvt  1:  Fundamental  Terms,  Bditioo  2. 1984 
Data  Promising  -  Vocabulary,  Fart  2:  Arithmetic  and  Logic  Operations.  1976 
Informatkm  Frooesaing  System*  -  Vocabulary,  Part  3:  Equipment  Technology,  Edition  2, 1987 
Information  Frooesaing  System*  -  Vocabulary,  Part  4:  Organization  of  Data,  Edition  2,  1987 
Information  Processing  Syrian*  •  Vocabulary,  Part  5:  Representation  of  Data,  Edition  2, 1989 
Information  Processing  Syrians  -  Vocabulary,  Pot  6:  Preparation  end  Handling  of  Data,  Edition  2, 
1987 


Information  Processing  Systems  •  Vocabulary,  Part  7:  Computer  Programming.  Edition  2, 1989 

Information  Processing  Systems  -  VocabuUry,  Part  8:  Control,  Integrity,  and  Security,  1986 

Data  Procuring  -  Vocabulary,  Part  9:  Data  Communication,  March  1984 

Data  Processing  -  Vocabulary,  Part  9:  Data  Communication,  Edition  2.  April  1991 

Data  processing  •  Vocabulary,  Part  10:  Operating  Techniques  and  Facilitate,  1979 

Information  Processing  Systems  -  Vocabulary,  Pot  11:  Processing  Units,  Edition  2, 1987 

Information  Proceaaing  System*  -  Vocabulary,  Part  12:  Peripheral  Equipment.  Edition  2, 1988 

Data  Processing  -  Vocabulary,  Part  13:  Computer  Graphics,  1984 

Data  Processing  •  VocabuUry,  Pot  14:  Reliability,  Maintenance,  and  Availability,  1978 


1  Based  on  data  initially  provided  by  OMNICON  hi  September  191  Revised  based  on: 

a.  ISO/IEC  JTC1/SC  21  Programme  of  Wort  [SC21  N  8082  1993] 

b.  ISO  Catabgm  [ISO  1993] 

c.  November  1993  Directory  offSPt  amt  Profile*  Contained  Therein,  SGFS  SIM  [SGFS  N  1049] 

d.  September  1993  NOSIP  Strategy  [NATO  1993] 

a.  Private  commnniration  from  UK's  Defence  Research  Agency  [DRA  1993] 
f.  Additional  contributions  from  the  nations  participating  in  the  ATCCIS  PWG. 

2  The  symbol  «  is  used  throughout  this  appendix  to  identify  thorn  standards  included  in  the  September  1993  NOSIP 
Straugy  [Ref.  NATO  1993], 
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UNCLASSIFIED 


no  230-13  Data  Process^  -  Vocabulary,  Part  13:  ProgrtMias  Languages,  1 985 

HO  2332-16  Data  Proosastaf  •  Vocabulary,  Part  16:  lafonaatfen  Theory,  197t 

DB  2332-17  Data  Pwqaestui  •  Vocabulary.  Part  17:  Datahaaai.  17  October  1933  (baBat  ends  April  1994) 

BO  2332-13  Information  hwaning  Syatama  •  Vocabulary,  Part  II:  DisMbntad  Data  ProosMlng,  1937 

ISO  2332-19  Information  Processing  Syatama  •  Vocabulary.  Part  19:  Analog  Computing,  Edition  2,  1939 

nOABC  2332-20  Informatioa  Proceaaing  Syatama  -  Vocabulary,  Part  20:  Syatam  development,  1990 

ISO  2332-21  Informatioa  Proceaaing  Syatama  -  Vocabulary,  Part  21:  Interfaces  Between  Proceaa  Computer 

Syatama  and  Technical  Processes,  1915 

ISO  2332-22  Informatioa  Proceaaing  Syatama  -  Vocabulary.  Part  22:  Calculator!,  1916 

CD  2332-23  Data  Proceaaing  -  Vocabulary,  Part  23:  Text  Proceaaing.  January  1991 

name  2332-2S  Drta  proceaaing  -  Vocabulary,  Pvt  2$:  Local  Area  Networks,  1992 

0B  2332-26  Data  Proceaaing  -  Vocabulary,  Part  26:  OSI  Architecture,  January  1992  (ballot  ended 

December  1992) 

ISO  2593:19344  Data  Commtmication  -  34-Pin  DTE/DCE  Open  Syatama  Interface  Connector  and  Pin  Assignments, 
Edition  2,  1934 

MS  25933  Data  Communicatioo  -  34-Pin  DTE/DCE  Open  Syatama  Interface  Connector  and  Pin  Assignments, 

Edition  3.  1992 

ISO  2628  Basic  Mode  Control  Prooaduma  -  Complements,  Juna  1973 

ISO  2629  Basic  Mode  Control  Procedures  -  Conversational  Information  Menage  Transfer,  February  1973 

ISO  2955  Information  Proceaaing  •  Representation  of  SI  and  Other  Units  in  Systems  with  Limited  Character 

Seta,  1983  (reviewed  in  1993  by  JTC1/SC14) 

ISO  3166  Codes  for  the  Representation  of  Names  of  Countries,  Edition  3, 1988  (ANSI/N1SQ/ISO  3166-1991) 

ISO  3307  Information  Interchange  -  Representations  of  Time  of  the  Day,  March,  1975 

ISO  3309:19844  Informatioa  Processing  Systems  •  Date  Communication  -  High-Level  Data  Link  Control  (HDLC) 

Procedures  -  Frame  Structure,  Edition  3,  Jane  1991 

ISO  3309:1991  Information  Technology  •  Telecommunication  and  Information  Exchange  Between  Syatama  -  High- 
Level  Data  Link  Control  (HDLC)  Procedures  -  Rama  Structure,  Edition  4,  Juna  1991 
ISO  3309:1991  AM  2*  Amendment  2:  Extended  Transparency  Option  for  Start/Stop  Transmission,  1992 
ISO  3309:1991  PDAM  3  Amendments:  Seven-bit  Transparency  Option  for  Start/Stop  Trwiawiaaion.  1991 
ISO  3534  Statistics  -  Vocabulary  and  Symbols.  1977 

ISO  4031  Information  Interchange  -  Representation  of  Local  lime  Differentials,  December  1987 

ISO  4335:1984e  Informatioa  Processing  Syatama  -  Data  Communication  -  High-Level  Data  Link  Control  (HDLC) 

Procedures,  Elements  of  Procedures,  Edition  3,  1904 

1SQAEC  4335:1991  Information  Technology  -  Telecomm anication  and  Information  Exchange  Between  Syatama  -  High- 

Level  Data  Unk  Control  (HDLC)  Procedures,  Elements  of  Procedures,  Draft  Edition  4,  1991 

ISOflBC  4335:1991  AM  4  Ameuchneat  4:  Multi-Selective  Reject,  1989 

ISOflEC  4335:1991  PDAD  5  Addendum  5:  Flow  Control  Unnumbered  Information  (FUI).  January  1991 
ISO  4*73  Information  Technology  -  8-Bit  Code  for  Information  Iatarchange  -  Structure  and  Rules  for 

Implementation.  Edition  2,  July  1991  (ANSI/ISO  4871-1991) 

ISO  4902e  Information  Technology  -  Data  Communication  -  37-Pole  DTE/DCE  Interface  Connector  and 

Contact  Number  Assignments,  Edition  2,  1989 

ISO  4903a  Information  Technology  -  Data  Communication  -  15-Pole  DTE/DCE  Interface  Connector  and 

Contact  Number  Assignments,  Edition  2,  1989 

ISO  5807  Information  Processing  -  Documentation  Symbols  and  Conventions  for  Data,  Program  and  System 

Flowcharts,  Program  Network  Charts  and  Syatam  Resource  Charts,  1985  (ANSMSO  5807-1985) 
ISO  6093  Information  Proceaaing  Syatama  -  Representation  of  Numeric  Values  in  Character  Strings  for 

Information  Exchange,  November  1985  (Reaffirmed  July  1991) 

ISO  6160  Programming  Languages  -  PL/1  (Endorsement  of  ANSI  Standard  X3 .53-1976),  1979 

150  6373  Data  Processing  -  Programming  Languages  -  Minimal  BASIC,  1984 

ISO  6429  ISO  7-Bit  and  8-Bk  Coded  Character  Sacs  -  Control  Amctiona  for  Coded  Cbaractar  Sate,  1992 

ISQ/IEC  6522  Information  Technology  •  Programming  Languages  •  PL/1  General  Propose  Subset,  Edition  2,  1992 

ISO  6523  Data  Interchange  -  Structure  for  the  Identification  of  Organizations,  February  1984 

ISO  6523  DAM  1  Gttidanee  on  the  Use  of  ISO  6523,  1993  (IS  states  expected  early  in  1994) 

ISO  6548  Data  Proceaaing  •  Description  of  Interface  Between  Process  Computing  System  and  Technical 

Process,  1984 

ISO  6592  Information  Proceaaing  -  Guidelines  for  the  Documentation  of  Computer-Based  Application 

Syatama,  November  1985 

ISO  6709  Standard  Representation  of  Latitude,  Longitude  and  Altitude  for  Geographic  Point  Locations,  1983 

(revieded  by  JTCI/SC14  in  1993) 

ISO  6936  Information  Proceaaing  -  Conversion  Between  the  Two  Coded  Character  Sets  of  ISO  646  and 

ISO  6937-2  and  the  COTT  International  Telegraph  Alphabet  No.  2  (ITA2),  Edition  2,  1988 
ISO  6937-1  Information  Proceaaing  -  Coded  Character  Seta  for  Text  Communication,  Part  1:  General 

Introduction,  November  1983 
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ISO  6937-2  Information  Processing  -  Coded  Character  Sets  for  Tat  Coamnnicatiod.  Put  2:  Latin  Alphabetic 

ad  Noo- Alphabetic  Graphic  Character*,  December  1983 
ISO  6937-2  AD  1  Addendum  1, 1989 

DIS  6937-2.2  Infonaatioo  Processing  -  Coded  Character  Sett  for  Text  Communication,  Pat  2:  Latin  Alphabetic 

and  Non- Alphabetic  Graphic  Character*,  Edition  2,  October  1991 
DIS  6937-3  Information  Processing  -  Coded  Character  Sett  for  Text  Communication,  Part  3:  Control  Faction* 

for  Page-Image  Format,  March  1988 

US  6937-7  Information  Processing  -  Coded  Character  Sett  for  Text  Communication,  Part  7:  Greek  Graphic 

Character*.  April  1987 

D(S  6937-8  Information  Processing  •  Coded  Character  Sett  for  Text  Communication.  Part  8:  Cyrillic  Graphic 

Characters,  April  1987 

ISO  6951  Information  Proceasing  -  Processor  System  Baa  Interface  (Enrobes  AX  1986 

ISO  7185  Information  Technology  •  Programming  Language*  -  Pascal,  Edition  2,  1990  (ANSMSO  7185- 

1990) 

ISQflEC  7350  Information  Technology  •  Registration  of  Repertoire*  of  Graphic  Characters  from  ISO  10367, 

Edition  2,  1991 

DIR  7352  Information  Technology  •  Guideline*  for  Grouping  of  Data  Element*  ha  the  Context  of  Data 

Interchange  (J7C1/SC14  recommended  in  November  1993  that  this  draft  technical  report  be 
withdrawn) 

ISCVTR  7477#  Data  Communication  -  Arrangement*  for  DTE  to  DTE  Physical  Connection  Uaing  V.24  and  X.24 

Interchange  Circuits,  September  1985 

ISO  7478*  Information  Processing  Systems  -  Data  Communication  •  Multilink  Ptocadmes,  July  1987 

ISO  7478/Cor  1  Technical  Corrigendum  1. 1  Merab  1989  [SC21  N  2738,  June  1988) 

ISOAEC  7480  Informatioo  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  -  Start- 

Stop  Transmission  Signal  Quality  at  DTE/DCE  Interfaces,  Edition  2.  October  1991 
ISO  7498:1984  Information  Processing  Systems  -  Open  Systems  Interconnection  •  Basic  Reference  Model, 
October  1984  [SC21  N  3273,  December  1988]  (reviakxi  incorporating  AD  1  ia  7498-1  below) 
(X.200) 

ISO  7498/Cor  1  Technical  Corrigendum  1.  IS  December  1988 

ISO  7498  AD  1«  Addendum  1:  Connectionless-Mode  Transmission.  July  1987 

ISO  7498  PD  AD  2  Addendum  2:  Multipeer  Dria  Transmission  (MPDT)  [SC21  N  3287)  (Reassessed  in  SC21  N  3906, 

September  1989;  project  suspended  in  November  1989  per  SC21  N  4276;  comments  on  reactivation 
of  project  requested  in  SC21  N  6197) 

1SO/IBC  7498-1:1994*  Information  Technology  •  Open  Systems  interconnection  -  Baric  Reference  Model,  Past  1: 
General  Aspects,  Edition  2. 1994  (SC21  N  8228] 

ISO  7498-2*  Informatioo  Processing  Systems  •  Open  Systems  Interconnection  -  Basic  Reference  Model.  Part  2: 

Security  Architecture,  February  1989  (XJ00:1991) 

ISO  7498-3*  Informatioo  Processing  Systems  •  Open  Systems  Interconnection  -  Basic  Reference  Model,  Part  3: 

Naming  and  Addnasing,  March  1989  (X. 650: 1992) 

ISCVIEC  7498-4*  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Baric  Reference  Model.  Part  4: 

Management  Framework.  November  1989  [SC21  N  3502]  (X. 700: 1992) 

WD  7498-5  Information  Processing  Systems  •  Open  Systems  Interconnection  -  Baric  Refertoce  Model,  Part  5: 

Architecture  to  Multi-Peer  Communications.  August  1993  [SC21  N  8003]  (ballot  rads 
November  1993;  CD  expected  in  1996) 

ISO  7776*  Information  Processing  Systems  -  Data  Communication  -  High-Level  Data  Link  Control  (HDLC) 

Procedures  -  Description  of  the  X2S  LAPB-Compatible  DIE  Date  Link  Procedures.  December  1986 
ISO  7776/Cor  1  Technical  Corrigendum  1,  1  April  1989 

ISO  7776/Cor  2  Technical  Corrigendum  2,  1  September  1989 

ISO  7776/Cor  3  Technical  Corrigendum  3,  1991 
ISO  7776  AM  1  Amendment  1:  Conformance  Requirements.  1992 

ISO  7809:1984*  Information  Processing  Systems  -  DsU  Communication  -  High-Level  Data  Link  Control  (HDLC) 
Procedures  -  Classes  of  Procedure*.  Edition  1, 1984 

ISCVIEC  7809:1991  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
High-Level  Data  Link  Control  (HDLC)  Procedures  -  Classes  of  Procedures,  Edition  2.  January  1991 
BKMBC  7809:1991  AM  5  Amendment  5:  Connectionless  Claes  of  Procedures.  1992 
ISCVIEC  7809:1991  AM  6  Amendment  6:  Extended  Transparency  Options  for  Sttrt/Stop  Tnmsmisaioc,  1992 
ISCVIEC  7809:1991  AM  7  Amendment  7:  Mnlti-Ssiective  Reject  Option,  Jransry  1991 
ISCVIEC  7809:1991  PDAM  9  Amendment  9:  Seveo-bit  Transparency  Option  for  Sttrt/Stop  Transmission.  1991 
ISO  7816-1  Information  Technology  •  Identification  Cards  •  Identification  Cards  with  Contacts,  Part  1: 

Physical  Characteristics,  1987,  SC  17/WO  (ANSI/ISO  7816/1-1987) 

ISO  7816-2  Information  Technology  -  Identification  Cards  -  Identification  Cards  with  Contacts,  Part  2:  Number 

and  Position  of  Contacts  1988,  SC  17/WO  (ANSI/ISO  7816/2-1988) 

ISO  7816-3  Informatioo  Technology  •  Identification  Cards  •  Identification  Cards  with  Contacts,  Part  3: 

Electronic  Signals/Exchange  Protocols,  SC17/WG4 
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DCS  7126-1 

DCS  7826-2 

ISO  7846 
ISO  7942 

ISO  7942  AM  1 
ISO  8072* 

ISO  8072/Cor  1 
ISO  8072  AD  1 
ISQflEC  1073* 

ISQAEC  8208* 

ISOflEC  8208/Cor  1 
ISQABC8208  AM  1 
ISQ/IEC  8208  PDAD  2 
ISQAEC  8208  AM  3 
ISO  8211 

DIS  8211.2 

ISO  8326* 

ISO  8326  AM  4 
ISO  8326  WD AM  3 

IMS  8326.2 

ISO  8327* 

ISO  8327  AM  3 

ISO  8327  WD  AM  4 

DCS  8327-1 

ISO  8327-2* 

ISO  8348:1993* 

ISO  8372 
ISO  8471* 

ISO  8473* 

ISO  8473/Cor  1 
ISO  8473  PD  ADI 

ISO  8473  PD  AD  2 

ISO  8473  AD  3 

ISO  8473  PDAM4 
ISO  8473  DAMS* 

ISO  8480 

ISO  8481* 

Appendix  E 


Information  Technology  •  Repreaentation  of  Data  Elements,  Part  1:  Identification  of  Coding 
Schemes  far  Data  Elements  (Types),  November  1993  (balloting  ended  February  1994) 

Information  Technology  •  Representation  of  Data  Elements,  Part  2:  Registration  of  Coding 
Schemas  for  Data  Elements  (Types),  November  1993  (balloting  ended  February  1994) 

Industrial  Real-time  FORTRAN  Application  for  the  Control  of  Industrial  Processes.  198S 
Information  Processing  Systems  -  Computer  Graphics  -  Graphics!  Kernel  System  (GKS)  Functional 
Description,  August  1983 
Amendment  1:  Audit  Trail  Metafile,  1991 

Information  Processing  Systems  -  Open  Systems  Interconnection  -  Transport  Service  Definition, 
June  1986  (ANSI/ISO  8072-1986) 

Technical  Corrigendum  1,  1991 

Addendum  1:  Connectionless-Mode  Transmission,  July  1986 

Information  Processing  Systems  -  Telecommunications  and  Information  Exchange  Between 
Systems  -  Protocol  for  Providing  the  Connection-mode  Transport  Service,  Edition  3.  1992 
Information  Processing  Systems  -  Data  Communications  -  X.2S  Packet  Level  Protocol  (PLP)  for 
Data  Terminal  Equipment,  Edition  2,  March  1990 
Technical  Corrigendum  1,  1992 

Amendment  1:  Alternative  Logical  Channel  Identifier  Assignment,  September  1990 
Addendum  2  -  Extensions  for  Private  and  Switched  Use  (project  canceled;  WITHDRAWN,  1989) 
Amendment  3:  Conformance  Requirements,  February  1991 

Information  Processing  -  Specification  for  a  Data  Descriptive  File  for  Information  Interchange, 
December  1983  (ANSI/ISO  8211-1983) 

Information  Processing  -  Specification  for  a  Data  Descriptive  File  for  Information  Interchange, 
Edition  2,  January  1993  [SC21  N  7333]  (passed  ballot  in  October  1993) 

Information  Processing  Systems  -  Open  Systems  Interconnection  -  Connection  Oriented  Session 
Service  Definition,  Revised  Edition,  1990  (incorporated  AD  1,  AD  2,  and  AD  3)  (X.215) 

Addendum  4:  Additional  Synchronization  Functionality,  December  1992 

Addendum  3:  Removal  of  Session  Layer  Serial  Number  Limitation,  August  1993  [SC21  N  7929] 
(rapporteur  meeting  December  1993;  PDAM  expected  July  1994) 

Information  Processing  Systems  •  Open  Systems  Interconnection  -  Connection  Oriented  Session 
Service  Definition,  Edition  2,  September  1993  [SC21  N  8207]  (X.213) 

Information  Processing  Systems  •  Open  Systems  Interconnection  -  Basic  Connection  Oriented 
Session  Protocol  Specification,  Revised  Edition  1990  (incorporated  AD  1  and  AD  2)  (X.223) 
Amendment  3  to  Incorporate  Additional  Synchronization  Functionality.  December  1992 
(SC21  N  7261] 

Amendment  4:  Removal  of  Seesion  Layer  Serial  Number  limitation.  August  1993  [SC21  N  7929] 
(rapporteur  meeting  December  1993;  PDAM  expected  July  1994) 

Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic  Connection  Oriented 
Session.  Pmt  1:  Protocol  Specification,  Edition  2  of  ISO  8327,  September  1993  [SC21  N  8208] 
(X.223) 

Information  Technology  -  Open  Systems  Interconnection  -  Basic  Connection  Oriented  Session 
Protocol  Specification,  Part  2:  Protocol  Implementation  Conformance  Statement  (PICS)  Proforma. 
1993  (X.243) 

Information  Processing  Systems  -  Data  Communications  •  Network  Service  Definition,  Edition  2, 
1993 

Information  Processing  •  Modes  of  Operation  for  a  64-bit  Block  Cipher  Algorithm.  1987 
Information  Processing  Systems  -  Data  Communication  -  High-Level  Data  Link  Control  (HDLC) 
Balanced  Classes  of  Procedures  -  Date-Link  Layer  Address  ResolutionfNegotiation  in  Switched 
Environments,  April  1987 

Information  Processing  Systems  -  Data  Communication  -  Protocol  for  Providing  the 

Connectionless-Mode  Network  Service  (CLNS),  January  1988 

Technical  Corrigendum  1,  1992  , 

Addendum  1:  Provision  of  Underlying  Service  Assumed  by  ISO  8473  over  Point-to-Point 
Subnetworks  which  Provide  the  OSI  Data  Link  Service,  July  1987  (DP) 

Addendum  2:  Estelle  Formal  Description  of  ISO  8473,  Revised  Edition,  April  1988  (to  be 
rebaJlotod  as  a  DTR) 

Addendum  3:  Pro  vision  of  the  Underlying  Service  Assumed  by  ISO  8473  over  Subnetworks  which 
Provide  the  OSI  Data  link  Service,  September  1989 
Amendment  4:  PICS  Proforma  (new  work  item) 

Amendment  3:  Provision  of  the  Underlying  Service  Assumed  by  ISO  8473  over  ISDN  Cbcuit- 
S witched  B -channels,  August  1991 

Information  Processing  •  Date  Communication  •  DTE/DCE  Interface  Back-up  Control  Operation 
Using  die  23-Pole  Connector,  November  1987 

Date  Communication  -  DTE  to  DTE  Physical  Connection  Using  X.24  Interchange  Circuits  with  DTE 
Providing  Timing,  September  1986 
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ISO  8482*  Information  Processing  System*  •  Data  Communication  •  Twisted  Pair  Multipoint  latorcoon actions, 

November  1987 

ISO  8485  Programming  Languages  -  APL,  1989 

US  8505  Information  Processing  Systems  •  Text  Communication  -  Functional  Description  and  Service 

Specification  for  Message  Oriented  Text  Interchange  Systems  (MOTIS),  February  1986 
(WITHDRAWN,  superseded  by  ISO  10021) 

ISO/TR  8509*  Information  Processing  Systems  •  Open  Systems  Interconnection  -  Service  Conventions, 

September  1987  (X.210:1988;  see  ISO  10731) 

ISO  8571-1*  Information  Processing  Systems  •  Open  Systems  Interconnection  -  File  Transfer,  Access  and 

Management  (FT AM),  Part  1:  General  Introduction,  Revised  Edition,  October  1988 
ISO  8571-1/Cor  1  Technical  Corrigendum  1,  June  1991 

ISO  8571-1  AM  1  Amendment  1:  Filestore  Management,  December  1992 

ISO  8571-1  AM  2  Amendment  2:  Overlapped  Access,  August  1993 

ISO  8571-1  AM  3  Amendment  3:  Service  Enhancement,  December  1993 

ISO  8571-1 WDAM  4  Amendment  4*.  Enhanced  Security  for  FT  AM,  May  1993  [SC21  N  7927)  (project  suspected  in 
July  1993  pending  resource  availability  and  stability  of  GULS) 

WD  8571-1.2  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Hie  Transfer,  Access  and 

Management  (FTAM),  Part  1:  General  Introduction,  Edition  2  (WD  expected  January  1994;  IS 
expected  December  1994) 

ISO  8571-2*  Information  Processing  Systems  •  Open  Systems  Interconnection  -  Hie  Transfer,  Access  and 

Management  (FTAM),  Part  2:  Virtual  Filestore  Definition,  Revised  Edition,  October  1988 
ISO  8571-2/Cor  1  Technical  Corrigendum  1,  June  1991 
ISO  8571-2  AM  1  Amendment  1:  Filestore  Management,  December  1992 
ISO  8571-2  AM  2  Addendum  2:  Overlapped  Access,  August  1993 

ISO  8571-2  PDAM  3  Amendment  3:  Enhancement  for  FTAM  Services  to  Satisfy  Additional  User  Requirements, 
March  1992  (SC 21  N  6787]  (project  suspected  in  1993) 

ISO  8571-2  WDAM  4  Amendment  4:  Enhancement  to  FTAM  Security  Services  (project  suspended  in  1993) 

WD  8571-2.2  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer,  Access  and 

Management  (FTAM),  Part  2:  Virtual  Filestore  Definition,  Edition  2  (WD  expected  January  1994; 
IS  expected  December  1994) 

ISO  8571-3*  Information  Proceaaing  Systems  -  Open  Systems  Interconnection  -  File  Transfer,  Access  and 

Management  (FTAM),  Part  3:  Hie  Service  Definition,  Revised  Edition,  October  1988 
ISO  8571-3/Cor  1  Technical  Corrigendum  1,  June  1991] 

ISO  8571-3/Cor  2  Technical  Corrigendum  2,  October  1992 

ISO  8571-3  AM  1  Amendment  1:  Filestore  Management,  December  1992 

ISO  8571-3  AM  2  Addendum  2:  Overlapped  Access,  August  1993 

ISO  8571-3  AM  3  Amendment  3:  Service  Enhancement.  December  1993 

ISO  8571-3  WDAM  4  Amendment  4:  Enhancement  to  FTAM  Security  Services  (Project  suspended) 

WD  8571-3.2  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer,  Access  and 

Management  (FTAM),  Part  3:  Hie  Service  Definition,  Edition  2  (WD  expected  January  1994;  IS 
expected  December  1994) 

ISO  8571-4*  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer,  Accees  and 

Management  (FTAM),  Part  4:  Hie  Protocol  Specification,  Revised  Edition,  October  1988 
ISO  8571-4/Cor  1  Technical  Corrigendum  1,  October  1992 
ISO  8571-4  AM  1  Amendment  1:  Filestore  Management,  December  1992 
ISO  8571-4  AM  2  Addendum  2:  Overlapped  Access,  August  1993 
ISO  8571-4  AM  3  Amendment  3:  Service  Enhancement,  December  1993 
ISO  8571-4  AM  4  Amendment  4:  Defect  Report  Changes,  November  1992 
ISO  8571-4  WDAM  5  Amendment  5:  Enhanced  Security  to  FTAM.  1992  (project  suspected  in  1993) 

WD  8571-4.2  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Hie  Transfer,  Access  and 

Management  (FTAM),  Part  4:  File  Protocol  Specification.  Edition  2  (WD  expected  January  1994;  IS 
expected  Decamber  1994) 

ISO/IEC  8571-5*  Information  Processing  Systems  •  Open  Systems  Interconnection  •  File  Transfer,  Access  and 
Management  (FTAM),  Part  5:  Protocol  Implementation  Conformance  Statement  Proforma,  Revised 
Edition,  December  1990 

ISO/IEC  8571-5  PDAM  1  Amendment  1:  Filestore  Management,  May  1992  [SC 21  N  7157]  (editing  meeting 
January  1994) 

ISO/IEC  8571-5  WDAM  2  Amendment  2:  Overlapped  Access,  June  1991  [SC21  N  6274]  (undergoing  reaesesnent;  in 
the  absence  of  an  editor  and  target  dates,  SC21  is  considering  this  project) 

ISO/IEC  8571-5  WDAM  3  Amendment  3:  Enhancement  for  FTAM  Services  to  Satisfy  Additional  User  Requirements, 
June  1991  [SC21  N  6223]  (to  be  progressed  as  a  technical  corrigendum) 

ISO/IEC  8571-5  WDAM  4  Amendment  4;  Enhancement  to  FTAM  Security  Services  (project  suspected  in  1993) 

WD  8571-5.2  Information  Processing  Systems  •  Open  Systems  Interconnection  -  File  Transfer,  Access  and 

Management  (FTAM),  Part  5:  Protocol  Implementation  Conformance  Statement  Proforma, 
Edition  2  (WD  expected  January  1994;  IS  expected  December  1994) 
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BO  N01  Dm  Bknaeu t»  and  lMnku|e  Formats  •  Information  Exchange  •  ffapraarnflina  of  Dalaa  aad 

Timas,  1988 

HOMO*  hhiaaHna  Ftooadi|  Systems  •  Open  Systems  InUrconoectiofi  -  Protocol  for  Providing  the 

CMaactoto  Mode  Tfansport  Service,  December  1987 
ISO  8602  DAM  1  Amendment  1:  PICS  Proforma 

ISO  8613-1*  Information  Processing  -  Text  and  Office  Systems  -  Office  Document  Architecture  (ODA)  and 

Intarrhangr  Format,  Part  1:  Introduction  and  General  Principles,  Inly  1988  [TA11] 

ISO  8613-1  AM  1  Amendment  1;  Document  Application  Profile  Proforma  and  Notation,  1993 

ISO  8613-1  AM  2  Amendment  2:  Conformance  Testing  Methodology,  1993 

ISO  8613-2*  Information  Processing  -  Text  and  Office  Systems  -  Office  Document  Architecture  (ODA)  and 

Interchange  Format,  Part  2:  Document  Structures,  1989  [T.412] 

ISO  8613-2  PDAD 1  Addmduml*.  Formal  Specification  of  ODA  Document  Structures 

DIS  8613-3  Information  Processing  -  Text  and  Office  Systems  -  Office  Document  Architecture  (ODA)  aad 

InSarcfaange  Format,  Part  3:  Abstract  Interface  for  Manipulation  of  ODA  Documents,  April  1993 
ISO  8613-4*  Information  Processing  -  Text  and  Office  Systems  -  Office  Document  Architecture  (ODA)  and 

Interchange  Format,  Part  4:  Document  Profile,  1989  (ITU-TS  T.414] 

ISO  8613-5*  Information  Processing  -  Text  and  Office  Systems  -  Office  Document  Architecture  (ODA)  and 

Intairhange  Format,  Pvt  5:  Office  Document  Interchange  Format  (ODIF),  1989  [T.415] 

ISO  1613-6*  Information  Processing  •  Text  and  Office  Systems  •  Office  Document  Architecture  (ODA)  and 

Totewhangr  Format,  Pvt  6:  Character  Content  Architectures,  1989  (T.416) 

ISO  8613-7*  Information  Processing  •  Text  and  Office  Systems  -  Office  Document  Architecture  (ODA)  and 

Interchange  Format,  Part  7:  Raster  Graphics  Content  Architectures,  1989  [T.417] 

ISO  8613-8*  Information  Processing  -  Text  rod  Office  Systems  -  Office  Document  Architecture  (ODA)  and 

Interchange  Format,  Part  8:  Geometric  Graphics  Content  Architectures,  1989  [TAll] 

ISO  8613-8  DAD  1  Addendum  1:  Tiled  Raster  Gr^ftics,  March  1990 

ISO  8613-8  DAM  2.2  Amendment  2:  Ccdor,  November  1990 

ISO  8613-8  DAD  3  Addendum  3:  Alternative  Representation,  Mwcfa  1990 

ISO  8613-8  DAD  4  Addendum  4:  Security,  Mach  1990 

ISO 8613-8 DAM 5.2  Amendments:  Streams, August  1991 

ISO  8613-8  DAD  6  Addendum  6:  Styles  Extension.  March  1990 

ISO  8613-8  PDAM 10  Amendment  10:  ODA  External  References  and  Document  Fragments 

CD  8613-9  Infonnarion  Processing  -  Text  and  Office  Systems  -  Office  Document  Architecture  (ODA)  end 

Intarrhenga  Format,  Fat  9:  Audio  Content  Architectures 

ISQffEC  8613-10  Information  Processing  .  Text  and  Office  Systems  •  Office  Document  Architecture  (ODA)  and 
Interchange  Format.  Part  10:  Formal  Specifications,  1991 

ISOffBC  1613-10  AM  1  Amendment  1:  Formal  Specification  of  the  Document  Profile  (ballot  closed  1  March  1991) 
ISOffBC  8613-10  AM  2  Amendment  2*  Formal  Specification  of  the  Raster  Graphics  Content  Architectures  (ballot  dosed 
1  March  1991) 

ISOffBC  8613-10  AM  3  Amendment  3:  Formal  Specification  of  ODA  Character  Coolant  Architectures,  1992 
ISOffBC  8613-10  AM  4  Amendment  4:  Formal  Specification  of  ODA  Geometric  Graphics  Content  AicMtactnree,  1992 
BQflBC  8613-10  AM  5  Amendment  S:  Formal  Specification  of  the  Defaulting  Mechanism  for  Defaultable  Attributes, 
1993 

CD  8613-11  ODA  Spreadsheet,  April  1993 

DB  8613-12  ODA  Identification  of  Document  Figments,  April  1993 

BOffBC  8631  Information  Technology  -  Program  Constructs  rod  Conventions  for  Their  Representation.  1989 

BOffBC  8632-1  Information  Technology  -  Computer  Graphics  -  Metafile  (COM)  for  the  Storage  and  Transfer  of 

Picture  Description  Information,  Part  1:  Functional  Specification,  Edition  2  1992 
BOffBC  8632-1  AM  I  Ammdmrotl:  Audit  Trail  Metafile,  1990 
BOffBC  8632-1  PDAD  2  Addendum  2  3D  Stalk  Picture  Capture  Metafile,  1989 
BOffBC  8632-1  DAM  3  Amendment  3,  Jrooary  1991 
BOffBC 8632-1  DAM 4  Amendment*  Rules  for  Profiles 

BOffBC  8632-2  Information  Processing  Systems  -  Computer  Graphics  -  Metafile  (COM)  for  the  Storage  and  Transfer 
of  Picture  Description  Information,  Part  2:  Character  Encoding,  Edition  2  1992 
BOffBC  8632-2  AM  I  Amendment  1,  1990 
BOffBC  8632-2  DAM  3  Addendum  3,  January  1991 

BOffBC  8632-3  Information  Processing  Systems  -  Computer  Graphics  -  Metafile  (COM)  for  the  Storage  rod  Transfer 
of  Picture  Description  Information,  Part  3:  Binary  Encoding,  Edition  2  1992 
BOffBC  8632-3  AM  1  Amendment  1,  1990 
BOffBC  8632-3  DAM  3  Amendment  3,  Jrouwy  1991 

BOffBC  8632-4  Information  Technology  -  Computer  Graphics  -  Metafile  (COM)  for  the  Storage  and  Transfer  of 
Picture  Description  Information,  Part  4:  Clear  Text  Encoding,  Edition  2  1992 
ISO  8648*  Information  Procersing  Systems  -  Open  Systems  Interconnection  -  Internal  Organisation  of  the 

Network  Lay*.  February  1988 
ISO  8648*Cor  1  Technical  Corrigendum  1, 1991 
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ISO  8649:1983*  Information  Proceuing  System*  ■  Open  Systems  Interconnection  -  Service  Definition  for  the 
Association  Control  Service  Element  (ACSE),  December  1988 
ISO  8649:1992  Information  Proceuing  Systems  -  Open  Systems  Interconnection  -  Service  Definition  for  the 
Association  Control  Service  Element  (ACSE),  Revised  Edition,  April  1992  (incorporates  AM  1  and 
AM  2)  (X.217:1992) 

ISO  8649:1992  DAM  3  Amendment  3:  Application-Context  Management  Service,  September  1993  [SC21  N  8046] 

ISO  8649  WDAM  4  Amendment  4:  Extensions  to  Support  the  Extended  Application  Layer  Structure,  December  1993 
[SC21/WG8  N  194] 

DIS  8649.2  Information  Proceuing  Systems  -  Open  Systems  Interconnection  -  Service  Definition  for  the 

Association  Control  Service  Element  (ACSE),  Edition  2  (IS  expected  November  1994)  (X.217) 

ISO  8650:1988*  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Protocol  Specification  for  the 
Association  Control  Service  Element  (ACSE),  December  1988 
ISO  8650:1992  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Protoad  Specification  for  the 
Association  Control  Service  Element  (ACSE),  Revised  Edition,  April  1992  (incorporates  AM  1) 
(X. 227: 1992) 

ISO  8650:1992  DAM  2  Amendment  2:  Application  Context  Negotiation  During  Association  Eatablishment, 
September  1993  [SC21  N  8047] 

ISO  8650:1992  WDAM  3  Amendment  3:  A -Coo  text  Management  Service  (formal  WD  text  expected  June  1992,  CD  AM 
in  June  1993,  DAM  June  1994,  AM  in  June  1995) 

ISO  8650  WDAM  4  Amendment  4:  Extensions  to  Support  the  Extended  Application  Layer  Structure,  December  1993 
[SC21/WG8  N  195] 

MS  8650-1  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Protocol  Specification  for  the 

Association  Control  Service  Element  (ACSE),  Edition  2  of  ISO  8650  (IS  expected  November  1994) 
(X.227) 

ISO  8650-2*  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Protocol  Specification  for  the 

Association  Control  Service  Element  (ACSE),  Part  2:  PICS  Proforma,  1993  [SC21  N  7003]  (X.247) 
ISO  8651-1  Information  Processing  Systems  -  Computer  Graphics  -  Graphical  Kernel  System  (GKS)  Language 

Bindings,  Part  1:  FORTRAN,  October  1988 

ISO  8651-2  Information  Proceuing  Systems  -  Computer  Graphics  -  Graphical  Kernel  System  (GKS)  Language 

Bindings,  Part  2:  Pascal,  October  1988 

ISO  8651-3  Information  Processing  Systems  -  Computer  Graphics  -  Graphical  Kernel  System  (GKS)  Language 

Bindings,  Part  3:  Ada,  October  1988 

ISCVIEC  8651-4  Information  Technology  •  Computer  Graphics  -  Graphical  Kernel  System  (GKS)  Language  Bindings, 
Part  4:  C.  1991 

ISO  8652  Programming  Languages  -  Ada  (Endorsement  of  ANSI  Standard  1815A-1983),  1987 

ISO  8730  Financial  Transactions  -  Wholesale  Banking  Security  -  Requirements  for  Message  Authentication, 

TC68/SC2 

ISO  8731-1  Financial  Transactions  -  Wholesale  Banking  Security  -  Approved  Algorithms  for  Message 

Authentication,  Part  1:  DEA-1  Algorithm,  TC68/SC2 

ISO  8731-2  Financial  Transactions  -  Wholesale  Banking  Security  -  Approved  Algorithms  for  Message 

Authentication,  Part  2:  Message  Authentication  Algorithm,  TC68/SC2 
ISO  8732  Financial  Transactions  -  Wholesale  Banking  Security  -  Key  Management.  7C68/SC6 

ISO  8790  Information  Processing  Systems  -  Computer  System  Configuration  Diagram  Symbols  and 

Conventions,  September  1987 

DP  8800-1  Information  Resource  Dictionary  System  (IRDS),  Part  1:  Command  Language  and  Panel  Interface 

(project  cancelled) 

ISO  8802-1*  Information  Proceuing  Systems  •  Local  Area  Networks,  Part  1:  General  Introduction,  1989 

DIS  8802-1.2  Information  Proceuing  Systems  -  Local  Area  Networks,  Part  1:  General  Introduction  with  System 

Load  Protocol,  November  1991 

ISO  8802-2*  Information  Proceuing  Systems  -  Local  Area  Networks,  Part  2:  Logical  Link  Control,  1989 

[ANSI/IEEE  802.2-1989] 

DIS  8802-2.2  Information  Processing  Systems  -  Local  Area  Networks,  Part  2:  Logical  i-tnir  Control,  Edition  2, 

July  1990 

ISO  8802-2.2/Cor  1  Technical  Corrigendum  1,  1992 

US  8802-2.2  DAM  1  Amendment  1:  Flow  Control  Techniques  for  Bridged  Local  Area  Networks,  May  1988 
US  8802-22  DAM  2  Amendment  2:  Type  3  Operation-Acknowledge  COonectionleu  Service,  June  1990 
MS  8802-22  DAM  3*  Amendment  3:  PICS  Proforma,  October  1991 
ns  8802-22  DAM  4  Amendment  4:  Editorial  Changes  and  Technical  Corrections,  May  1990 
US  8802-22  PDAM  5  Amendment  5:  Bridged  LAN  Source  Routing  Operations  by  End  Systems,  August  1991 
ISO/IEC  8802-3*  Information  Technology  -  Local  and  Metropolitan  Area  Networks,  Part  3:  Carrier  Sense  Multiple 
Acceu  with  Collision  Detection  (CSMA/CD)  Access  Method  and  Physical  Layer  Specifications, 
Edition  3,  1992  [ANSI/IEEE  802-3-1992] 

ISO/IEC  8802-3  DAM  6  Amendment  6:  Summary  of  1BKR  802.3,  August  1991 
ISOAEC  8802-3  DAM  7  Amendment  7:  LAN  Layer  Mmagement,  October  1991 
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I3CMBC  MS-3  DAM  9  Amendment  9;  Twisted  Pair,  Medium  Attachment  Unit,  and  Baseband  Medium  Specifications, 
Type  10  BASE-T,  September  1991 

ISQflEC  8802-3  PD  AM  11  Ameadaeot  11:  Hub  Management,  March  1992 

ISQflEC  8802-3  PD  AM  13  Amendment  13:  Attachment  Unit  Interface  Cable  Conformance  Test,  March  1992 
ISCVIEC  8802-3  PD  AM  15  Amendment  15:  Corrections  and  Updates  2  A  3,  March  1992 
ISQflEC  8802-3  PDAM  17  Ameocknent  17:  PICS  Proforma  for  10  BASE-T.  March  1992 

ISCVIEC  8800-4*  Information  Technology  -  Local  Area  Networks,  Part  4:  Token-Passing  Bus  Access  Method  and 
Physical  Layer  Specifications,  Edition  2,  August  1990  [ANSI/IEEE  802-4-1990] 

ISCVIEC  8802-5*  Information  Technology  -  Local  and  Metropolitan  Area  Networks.  Part  5:  Token  Ring  Access 
Method  and  Physical  Layer  Specification,  Revised  Edition  containing  Part  5  and  its  first  3  addenda, 
1992  [ANSMEEE  802-5-1991] 

US  8802-6*  Information  Processing  Systems  •  Local  Area  Networks,  Part  6:  Distributed  Queue  Dual  Bus  (DQDB) 

Madia  Access  Control  (MAC),  August  1991 

ISO  8802-7  Information  Technology  -  Local  Area  Networks,  Part  7:  Slotted  Ring  Access  Method  and  Physical 

Layer  Specification,  1991 

MS  8802-9*  Information  Processing  Systems  -  Local  Area  Networks,  Part  9:  Integrated  Voice  and  Data  (TVD) 

Local  Area  Network 

CD  8802-51  Information  Processing  Systems  -  Local  Area  Networks,  Part  51:  MAC  Sublayer  Conformance  Test 

Purposes,  December  1991 

ISO  8805  Information  Processing  Systems  -  Computer  Graphics  -  Graphical  Kernel  System  for  Three 

Dimensions  (GKS-3D)  Functional  Description,  October  1988 
ISO  8805  WD ADI  Addendum  1:  Name  Set  Addendum,  April  1987  (WD) 

D1S  8806-1  Information  Processing  Systems  -  Computer  Graphics  -  Graphical  Kernel  System  for  Three 

Dimensions  (GKS-3D)  Language  Bindings,  Part  1:  FORTRAN,  November  1988 
MS  8806-3  Information  Processing  Systems  -  Computer  Graphics  -  Graphical  Kernel  System  for  Three 

Dimensions  (GKS-3D)  Language  Bindings,  Part  3:  Ada,  1989 

ISQflEC  8806-4  Information  Technology  -  Computer  Graphics  •  Graphical  Kernel  System  for  Three  Dimensions 
(GKS-3D)  Language  Bindings,  Part  4:  C,  1991 

ISO  8807  Information  Processing  Systems  -  Open  Systems  Interconnection  -  LOTOS  -  A  Formal  Description 

Technique  Based  on  the  Temporal  Ordering  of  Observational  Behaviour,  February  1989  (Z.100) 

ISO  8807  AMI  Addendum  1,  Graphical  Representation  of  LOTOS  (G-LOTDS),  1993  [SC21  N  6751] 

ISO  8807  WD  AM  2  Amendment  2:  Enhancements  to  LOTOS.  July  1993  [SC21  N  8023)  (new  work  item  ballot  ends 

November  1993;  rapporteur  meeting  January  1994;  PDAM  expected  June  1995) 

ISO  8822*  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Connection  Oriented 

Presentation  Service  Definition,  August  1988  (X.216) 

ISO  8822  AM  1*  Amendment  1:  Connectionless-Mode  Presentation  Service,  September  1991 
ISO  8822  AM  2  Amendment  2:  Unlimited  User  Data,  1993  [SC 21  N  7419] 

ISO  8822  DAM  3  Amendment  3:  Abstract  Syntax  Registration,  January  1993  [SC21  N  7556] 

ISO  8822  AM  4  Amendment  4:  Support  of  Session  Symmetric  Synchronization  Service,  November  1993 

ISO  8822  AM  5  Amendment  5:  Delivery  of  Additional  Session  Synchronization  Functionality  to  the  Presentation 

Service  User.  December  1992 

DES  8822.2  Information  Processing  Systems  •  Open  Systems  Interconnection  -  Connection  Oriented 

Presentation  Service  Definition,  Edition  2.  August  1993  [SC21  N  8173]  (incorporates  AMI  to 
AM5)  (X.216) 

ISO  8823*  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Connection  Oriented 

Presentation  Protocol  Specification,  August  1988  [SC21  N  2336,  April  1988]  (defect  reports  SC21 
N  3751-3760,  August  1989)  (X.226) 

ISO  8823  AM  2  Amendment  2:  Unlimited  User  Dsta,  1993  [SC21  N  7420] 

ISO  8823  DAM  3  Amendment  3:  Transfer  Syntax  Registration,  January  1993  [SC21  N  7557] 

ISO  8823  AM  4  Amendment  4:  Support  of  Session  Symmetric  Synchronization  Service,  November  1993 

ISO  8823  AM  5  Amendment  5:  Additional  Synchronization  Functionality  to  the  Presentation  Service  User, 
December  1992  [SC21  N  7263] 

MS  8823-1  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Connection  Oriented 

Presentation  Protocol  Specification,  Edition  2  of  ISO  8823  [SC21  N  8174]  (IS  expected  in  1994) 
(X.226) 

ISQflEC  8823-2*  Information  Technology  •  Open  Systems  Interconnection  -  Connection  Oriented  Presentation 
Protocol  Specification,  Part  2:  Presentation  Protocol  Implementation  Conformance  Statement 
(PICS)  Proforma,  1993  (initiation  of  ITU-T'S  approval  ballot  expected  February  1994)  (X.246) 
ISQflEC  8824*  Information  Technology  -  Open  Systems  Interconnection  •  Specification  of  Abstract  Syntax 

Notation  One  (ASN.l).  April  1990,  Edition  2  (incorporates  AD  1)  [SC21  N  4720]  (X.208) 

ISCVIEC  8824/Cor  1  Draft  Technical  Corrigendum  1,  November  1993  [SC21  N  8317] 

ISQflEC  8824  DAM  2  Amendments  to  ISO  8824  to  Give  ISO  8824  Part  1:  Specification  of  Bask  Notation,  August  1992 
(SC21  N  7308]  (result  is  8824-1;  see  below) 

ISQflEC  8824  PDAM  3.2  Amendment  3:  Rules  of  Extensibility,  14  August  1992  [SC21  N  6981] 
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ISQ/IEC  8824-1  Information  Technology  -  Open  System  Interconnection  •  Specification  of  Abstract  Syntax 
Notation  One  (ASN.l),  Part  1:  Specification  of  Basic  Notation  (Edition  3  of  ISO  8824), 
October  1992  (initiation  of  ITU-TS  approval  ballot  expected  February  1994)  (X.680) 

ISQ/IEC  8824-1  WDAM  4  Amendment  4:  Removal  of  Definition  of  Root  Arcs  of  Object  Identifier  Tree  (WDAM  expected 
August  1994,  PDAM  December  1994,  DAM  December  1993,  and  AM  December  1996) 

ISO/IEC  8824-2  Information  Technology  -  Open  Systems  Interconnection  •  Specification  of  Abstract  Syntax 
Notation  One  (ASN.l),  Part  2:  Information  Object  Specification,  October  1992  (initiation  of  ITU- 
TS  approval  ballot  expected  February  1994)  (X.681) 

ISQ/IEC  8824-3  Information  Technology  -  Open  Systems  Interconnection  -  Specification  of  Abstract  Syntax 
Notation  One  (ASN.l).  Part  3:  Constraint  Specification,  October  1992  (initiation  of  ITU-TS 
approval  ballot  expected  February  1994)  (X.682) 

ISQ/IEC  8824-4  Information  Technology  -  Open  Systems  Interconnection  -  Specification  of  Abstract  Syntax 
Notation  One  (ASN.l),  Part  4:  Parameterization  of  ASN.l  Specifications,  October  1992  (initiation 
of  ITU-TS  approval  ballot  expected  February  1994)  (X.683) 

ISQ/IEC  8823*  Information  Technology  -  Open  Systems  Interconnection  -  Specification  of  Basic  Encoding  Rules 

for  Abstract  Syntax  Notation  One  (ASN.l),  Edition  2  (incorporates  AD  1),  April  1990  (X.209) 
ISO/IEC  8823/Cor  1  Draft  Technical  Corrigendum  1,  November  1993  (SC21  N  8317] 

ISQ/IEC  8823  DAM  2  Amendments  to  ISO  8823  to  Give  ISO  8823  Part  1:  Basic  Encoding  Rules,  19  August  1992 
[SC21  N  7312] 

ISO/IEC  8825  AM  3  Amendment  3:  Rules  for  Extensibility,  June  1992  [SC21  N  6981] 

DIS  8823-1  Information  Technology  -  Open  Systems  Interconnection  -  Specification  of  Specification  of  Basic 

Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.l),  Part  1:  Basic  Encoding  Rules  (BER) 
(revised  edition  of  ISO  8823)  (X.690)  (IS  expected  February  1994)  (X.690) 

DIS  8825-1  WDAM  1  Amendment  1:  Light  Weight  Encoding  Rules  for  ASN.l.  August  1993  [SC21  N  7920] 

DIS  8823-2.2  Information  Technology  -  Open  Systems  Interconnection  -  Specification  of  Basic  Encoding  Rules 

for  Abstract  Syntax  Notation  One  (ASN.l),  Part  2:  Packed  Encoding  Rules  (PER),  1993 
[SC21  N  7302]  ('nidation  of  ITU-TS  approval  ballot  expected  June  1995)  (X.691) 

DIS  8825-3  Information  Technology  -  Open  Systems  Interconnection  -  Specification  of  Basic  Encoding  Rules 

for  Abstract  Syntax  Notation  One  (ASN.l).  Part  3:  Distinguished  and  Canonical  Encoding  Rules 
(X.692)  (To  be  merged  into  text  of  DIS  8825-1),  October  1992  [SC21  N  7313] 

DIS  8825-4  Information  Technology  -  Open  Systems  Interconnection  -  Specification  of  Basic  Encoding  Rules 

for  Abstract  Syntax  Notation  One  (ASN.l),  Part  4.  Test  Suite  Structure  and  Test  Purposes  for  ASN.l 
Encodings.  SC21/WG6,  July  1990  [SC21  N  5019] 

ISO/IEC  8831  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Job  Transfer  and  Manipulation 

(JTM)  Concepts  and  Service,  Edition  2,  March  1992 

ISO/IEC  8832  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification  of  the  Basic  Class 

Protocol  for  Job  Transfer  and  Manipulation  (JTM),  Edition  2.  March  1992 

ISO  8859-1  Information  Processing  -  8-Bit  Single-Byte  Coded  Graphic  Character  Sea.  Part  1:  Latin  Alphabet 

No.  1.  February  1987  (ANSI/ISO  8859-1-1987) 

ISO  8839-2  Information  Processing  -  8-Bit  Single-Byte  Coded  Graphic  Character  Sets,  part  2:  Latin  Alphabet 

No.  2.  February  1987 

ISO  8859-3  Information  Processing  -  8-Bit  Single-Byte  Coded  Graphic  Character  Sea,  Part  3:  Latin  Alphabet 

No.  3.  April  1988 

ISO  8859-4  Information  Processing  -  8-Bit  Single-Byte  Coded  Graphic  Character  Sets,  Part  4:  Latin  Alphabet 

No.  4.  April  1988 

ISO/IEC  8859-5  Information  Processing  -  8-Bit  Single-Byte  Coded  Graphic  Character  Sets,  Part  5:  Latin/Cyrillic 
Alphabet.  1988 

ISO  8859-6  Information  Processing  -  8-Bit  Single-Byte  Coded  Graphic  Character  SeU,  Part  6:  Latin/Arabic 

Alphabet,  August  1987 

ISO  8839-7  Information  Processing  -  8-Bit  Single-Byte  Coded  Graphic  Character  SeU,  Part  7:  Latin/Greek 

Alphabet,  November  1987 

ISO  8859-8  Information  Processing  -  8-Bit  Single-Byte  Coded  Graphic  Character  Sets,  Part  8:  Latin/Hebrew 

Alphabet,  1988 

ISO/IEC  8859-9  Information  Processing  -  8-Bit  Single-Byte  Coded  Graphic  Character  SeU,  Part  9:  Latin  Alphabet 
No.  5.  1989 

ISO/IEC  8839-10  Information  Processing  -  8-Bit  Single-Byte  Coded  Graphic  Character  SeU,  Part  10:  Latin  Alphabet 
No.  6,  1992 

ISO/IEC  8877*  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 

Interface  Connector  and  Contact  Assignments  for  ISDN  Buie  Access  Interface  Located  at  Reference 
Poinu  S  and  T,  1992 

ISO/IEC  8877  AM  1  Amendment  1 :  Standard  ISDN  Buie  Access  TE  Connecting  Cord,  May  1993 
ISO/IEC  8878*  Information  Technology  -  Data  Communications  -  Use  of  X.23  to  Provide  the  OSI  Connection- 

Mode  Network  Service  (CONS),  Edition  2,  1992  (X.223) 

ISO/IEC  8878-2  Information  Processing  Systems  •  Data  Communications  -  Use  of  X.25  to  Provide  the  OSI 
Connection-Mode  Network  Service  (CONS),  Part  2:  Protocol  Implementation  Conformance 
Statement  (PICS),  1992 
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ISQ/IEC  SttO-U  Information  Technology  -  Telecommunications  end  Information  Exchange  Between  Systems  - 
Protocol  Combination  to  Provide  and  Support  the  OSI  Network  Sendee,  Part  1:  General  Principles, 
1992 

ISQ/IEC  8880-2*  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Protocol  Combination  to  Provide  and  Support  the  OSI  Network  Service,  Part  2:  Provision  and 
Support  of  the  Connection-Mode  Network  Services,  1990 
ISQ/IEC  8880-2  DAM  1  Amendment  1:  Addition  of  the  ISDN  Environment  (awaiting  DAM  ballot) 

ISQ/IEC  8880-2  PD  AM  2  Amendment  2:  Addition  of  the  PSTN  and  CSDN  Environments  (awaiting  PDAM  ballot) 

ISQ/IEC  8880-3*  Information  Processing  Systems  -  Protocol  Combination  to  Provide  and  Support  the  OSI  Network 
Service,  Pert  3:  Provision  and  Support  of  the  Connectionless-Mode  Network  Service,  1990 
ISQ/IEC  8880-4*  Information  Processing  Systems  -  Protocol  Combination  to  Provide  and  Support  the  OSI  Network 
Service,  Part  4:  Interconnection  of  OSI  Environments,  1993 

ISQ/IEC  8881*  Information  Processing  Systems  -  Data  Communications  -  Use  of  the  X.25  Packet  Level  Protocol 

(PLP)  in  Local  Area  Networks,  1993 

ISO  8882  Information  Processing  Systems  -  X.25-DTE  Conformance  Testing,  Part  1:  General  Principles, 

1989 

ISQ/IEC  8882-1  Information  Processing  Systems  •  X.2S-DTE  Conformance  Testing,  Part  1:  General  Principles, 
Edition  2  of  ISO  8882,  1993 

ISQ/IEC  8882-2  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  • 
X.25-DTE  Conformance  Testing,  Part  2:  Data  1-inlr  Layer  Conformance  Test  Suite,  1992 
ISQ/IEC  8882-3  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
X.2S-DTE  Conformance  Testing,  Part  3:  Packet  Level  Conformance  Suite.  Edition  3,  May  1991 
IMS  8883  Information  Processing  Systems  •  Text  Communication  -  Message  Oriented  Text  Interchange 

System,  Message  Transfer  Sublayer,  Message  Interchange  Service  and  Message  Transfer  Protocol, 
February  1986  [WITHDRAWN,  superseded  by  ISO  10021-6) 

ISO  8884  Information  Processing  -  Text  and  Office  Systems  -  Keyboards  for  Multiple  Latin-Alpfaabet 

Languages  -  Layout  and  Operation  Using  Four  Levels,  1989 

ISO  8885:1987*  Information  Processing  Systems  •  Data  Communication  -  High-Level  Data  Link  Control  (HDLC) 
Procedures  -  General  Purpose  XID  Frame  Information  Field  Content  and  Format,  Edition  1, 1987 
ISO/IEC  8885  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 

High-Level  Data  Link  Control  (HDLC)  Procedures  -  General  Purpose  XID  Frame  Information  Field 
Content  and  Format,  Edition  2,  1991 

ISQ/IEC  8885  AM  3  Amendment  3:  Definition  of  a  Private  Parameter  Negotiation  Data  Link  Layer  Snbfield. 
August  1992 

ISQAEC  8885  AM  4  Amendment  4:  Extended  Transparency  Options  for  Start/Stop  Transmission,  1992 

ISQ/IEC  8885  AM  5  Amendment  5:  Multi-Selective  Reject  Option,  January  1991 

ISQ/IEC  8885  PDAM  6  Amendment  6:  Seven-bit  Transparency  Option  for  Start/Stop  Transmission.  1991) 

ISQ/IEC  8885  PDAM  7  Amendment  7:  Frame  Check  Sequence  Negotiation  Using  the  Parameter  Negotiation  Subfield 
(ballot  closed  21  August  1990) 

ISQ/IEC  8886*  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  -  Data 

Link  Service  Definition  for  Open  Systems  Interconnection,  Third  Revision,  1992 
ISO  8907  Information  Processing  Systems  -  Database  Languages  -  NDL,  June  1987 

ISO  9000  Quality  Management  and  Quality  Assurance  Standards  -  Guidelines  for  Selection  and  Use,  1987 

ISO  9000-3  Quality  Management  and  Quality  Assurance  Standards,  Part  3:  Guidelines  for  the  Application  of  ISO 

9001  to  the  Development,  Supply,  and  Maintenance  of  Software,  1991 
ISO  9001  Quality  Systems  •  Model  for  Quality  Assurance  in  Design/Development,  Production,  Installation 

and  Servicing,  1987 

ISO  9002  Quality  Systems  •  Model  for  Quality  Assurance  in  Production  and  Installation.  1987 

ISO  9003  Quality  Systems  -  Model  for  Quality  Assurance  in  Final  Inspection  and  Test,  1987 

ISO  9004  Quality  Management  and  Quality  System  Elements  -  Guidelines.  1987 

ISO  9004-2  Quality  Management  and  Quality  System  Elements,  Part  2:  Guidelines  for  Services.  1991 

ISQ/TR  9007  Information  Processing  Systems  •  Concepts  and  Terminology  for  the  Conceptual  Schema  and  the 

Information  Base,  July  1987 

ISO  9036  Information  Processing  -  Arabic  7-bit  Coded  Character  Set  for  Information  Exchange,  1987 

ISO  9040*  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Virtual  Terminal  (VT)  Service  - 

Base  Class,  Revised  Edition  (incorporates  AD  1),  November  1990 
ISO  9040/Cor  1  Technical  Corrigendum  1.  April  1991 

ISO  9040/Cor  2  Technical  Corrigendum  2,  December  1992 

ISO  9040/Cor  3  Technical  Corrigendum  3,  September  1993 

ISO  9040  AM  2*  Amendment  2:  Additional  Functional  Units,  October  1992  [SC21  N  7878] 

ISO  9041-1:1990*  Information  Processing  Systems  •  Open  Systems  Interconnection  -  Virtual  Terminal  (VT)  Protocol, 
Part  1:  Specification,  Revised  Edition  of  ISO  9041  (incorporates  AD  1),  November  1990 
ISO  9041-1/Cor  1  Technical  Corrigendum  1,  December  1992 

ISO  9041-1/Cor  2  Technical  Corrigendum  1,  September  1993 

ISO  9041-1  AM  2*  Amendment  2:  Additional  Functional  Units,  October  1992 

Appendix  E  E-10  Standards  By  Number 

UNCLASSIFIED 


UNCLASSIFIED 


ISO  9041-2*  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Virtual  Terminal  (VT)  Protocol, 

Part  2:  VT  PICS  Proforma,  1993  (DIS  ballot  ended  October  1991) 

NS  9065  Information  Processing  Systems  -  Text  Communication  -  Message  Oriented  Text  Interchange 

System  (MOTIS)  User  Agent  Sublayer  -  Interpersonal  Messaging  User  Agent  -  Message  Interchange 
Formats  and  Protocols,  February  1986  [withdrawn;  superseded  by  ISO  10021] 

ISO/IEC  9066-1*  Information  Processing  Systems  -  Text  Communication  -  Reliable  Transfer  (RT),  Part  1:  Model  and 
Service  Definition,  Revised  Edition.  September  1989  [SC21  N  3883]  (X.218) 

ISO/IEC  9066-2*  Information  Processing  Systems  -  Text  Communication  -  Reliable  Transfer  (RT),  Part  2:  Protocol 
Specification,  Revised  Edition,  September  1989  [SC21  N  3884]  (X.228) 

ISOTEC  9066-2/Cor  1  Technical  Corrigendum  1,  September  1993  [SC21  N  8077] 

IKS  9066-3  Information  Processing  Systems  -  Text  Communication  -  Reliable  Transfer  (RT),  Part  3:  PICS 

Proforma,  March  1993  [SC21  N  7677]  (initiation  of  ITU-TS  approval  ballot  expected  June  1995) 
(X.248) 

ISO  9067  Information  Processing  Systems  -  Data  Communication  -  Automatic  Fault  Isolation  Procedures 

Using  Test  Loops,  September  1987 

IKS  9068*  Information  Processing  Systems  •  Provision  of  the  Connectionless  Network  Service  (CONS)  Using 

ISO  8208,  1989 

ISO  9069  Information  Processing  -  SGML  Support  Facilities  -  SGML  Document  Interchange  Format  (SDIF), 

September  1988 

ISO/IEC  9070  Information  Processing  -  SGML  Support  Facilities  -  Registration  Procedures  for  Public  Text  Owner 

Identifiers,  Edition  2,  April  1991 

DP  9071-1.2  Text  and  Office  Systems  -  Basic  and  Optional  Requirements,  Part  1:  Facsimile  Equipment, 

Revision  2,  January  1987 

DP  9071-2.2  Text  and  Office  Systems  -  Basic  and  Optional  Requirements,  Part  2:  Text  Communications 

Terminals,  Revision  2,  January  1987 

ISO  9072-1:1989*  Information  Processing  Systems  -  Text  Communication  -  Remote  Operations,  Part  1:  Model, 
Notation  and  Service  Definition.  Revised  Edition,  September  1989  [SC21  N  3881]  (X.219) 

ISO  9072-1  PD  AM  1  Amendment  1:  Enhancements  to  Service  Definition,  April  1992  [SC21  N  6717]  (to  JTC1  for 
endorsement  to  cancel  the  project) 

ISO/IEC  9072-1:1993  Information  Processing  Systems  •  Text  Communication  -  Remote  Operations,  Part  1:  Concepts, 
Model  and  Notation,  Edition  2.  March  1993  [SC21  N  7669]  (passed  IKS  ballot  in  October  1993) 
(X.219)  (see  IKS  13712-1) 

ISO/IEC  9072-1  PDAM  1  Amendment  1:  Built-In  Operations.  June  1993  [SC21  N  8073] 

ISO/IEC  9072-2:1989*  Information  Processing  Systems  •  Text  Communication  -  Remote  Operations.  Part  2:  Protocol 
Specification.  Revised  Edition,  September  1989  [SC21  N  3882]  (X.229) 

ISO/IEC  9072-2  PDAM  1  Amendment  1:  Enhancements  to  Protocol  Specification,  April  1992  [SC21  N  6718]  (to  JTC1 
for  endorsement  to  cancel  the  project) 

ISO/IEC  9072-2:1993  Information  Processing  Systems  -  Text  Communication  -  Remote  Operations,  Part  2:  Service 
Definition,  Edition  2,  March  1993  (passed  DIS  ballot  in  October  1993)  [SC21  N  7670]  (see 
DIS  13712-2) 

ISO/IEC  9072-2  PDAM  1  Amendment  1:  Mapping  to  A-UNITDATA  and  Built-In  Operations.  July  1993  [SC21  N  8074] 
ISO/IEC  9072-3:1993  Information  Processing  Systems  -  Text  Communication  -  Remote  Operations.  Part  3:  Protocol 
Specification,  March  1993  (passed  DIS  ballot  in  October  1993)  [SC21  N  8074]  (see  IKS  13712-3) 
ISO/IEC  9072-3  PDAM  1  Amendment  1:  Mapping  to  A-UNITDATA  and  Built-In  Operations,  June  1993  [SC21 N  8075] 
ESS  9072-4  Information  Processing  Systems  -  Text  Communication  -  Remote  Operations.  Part  4:  PICS 

Proforma,  December  1993  [SC21  N  7678]  (initiation  of  ITU-TS  approval  ballot  expected 
November  1994)  (X.249)  (see  CD  13712-4) 

ISO  9074:1989  Information  Processing  Systems  -  Open  Systems  Interconnection  •  Estelle  -  A  Formal  Description 
Technique  Based  on  an  Extended  State  Transition  Model  July  1989 
ISO  9074  AM  1  Amendment  1:  Estelle  Tutorial,  1993 

WD  9074.2  Information  Technology  -  Open  Systems  Interconnection  -  Estelle  -  A  Formal  Description 

Technique  Based  on  an  Extended  State  Transition  Model,  Edition  2  (incorporates  AM  1) 

ISO  9075:1988  Information  Processing  Systems  -  Database  Language  SQL,  April  1989  (revised  text  incorporates 
AD  1)  [SC21  N  3158] 

ISO  9075:1992  Information  Technology  -  Database  Languages  -  SQL2,  November  1992  (technical  content  of 
ISO  9075:1988  is  retained  as  a  level  of  the  1992  standard) 

ISO  9075: 1992/Cor  1  Technical  Corrigendum  1,  January  1994  [SC 21  N  8432] 

WD  9075-x  Information  Processing  Systems  •  Database  Languages  •  SQL,  Part  x:  SQL  Call  Level  Interface 

(CL1),  January  1993  [SC21  N  7596]  (CD  expected  January  1994) 

WD  9075 -y  Information  Processing  Systems  -  Database  Languages  -  SQL,  Part  y:  Persistent  SQL  Modules, 

January  1993  [SC21  N  7597]  (CD  expected  January  1994) 

WD  90753  Information  Processing  Systems  -  Database  Languages  -  SQL3,  May  1992  [SC21  N  6931  and 

SC21 N  8091]  (CD  text  expected  July  1994;  IKS  July  1995;  IS  July  1996) 

ISO/IEC  9126  Information  Technology  -  Software  Product  Evaluation  -  Quality  Characteristics  sod  Guidelines  for 

Their  Use,  1991 
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ISO  9127 

ISO  9160 

ISO  9171-1 

ISO  9171-2 

MS  9234 
ISO  9241-1 

ISO  9241-2 

ISO  9241-3 

MS  9241-4 

CD  9241-5 

CD  9241-6 

CD  9241-7 

CD  9241-8 

CD  9241-9 

WD  9241-10 

CD  9241-11 

CD  9241-12 

WD  9241-13 
CD  9241-14 
WD  9241-15 

WD  9241-16 

WD  9241-17 

XX  9241-18 

XX  9241-19 

ISO  9281-1 

ISO  9281-2 

ISO  9282-1 

ISO  9282-2 

ISOAEC  TR  9294 

ISO  9314-1* 

ISO  9314-2« 

ISOfflBC  9314-3* 

ISCVTEC  9314-4* 

DIS  9314-5* 


Information  Procuring  Systems  -  User  Documentation  and  Cover  Information  for  Consumer 
Software  Packager,  1988 

Information  Processing  -  Data  Encipherment  -  Physical  Layer  Interoperability  Requirements, 
February  1988 

Information  Technology  -  130  mm  Optical  Disk  Cartridge,  Write  Once,  for  Information 
Interchange,  Part  1:  Unrecorded  Optical  Disk  Cartridge,  1990 

Information  Technology  -  130  mm  Optical  Disk  Cartridge,  Write  Once,  for  Information 
Interchange,  Part  2:  Recording  Format,  1990 

Industrial  Asynchronous  Data  Link  for  Two-Way  Simultaneous  or  Two-Way  Alternate  Mode,  1989 
Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  1 :  Introduction, 
1992 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  2:  General  Guidance 
on  Task  Requirements.  1992 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  3:  Visual  Display 
Requirements,  1992 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  4:  Keyboard 
Requirements 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  5:  Workstation 
Layout  and  Postural  Requirements 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  6:  Environmental 
Requirements 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  7:  Display 
Requirements  with  Reflections 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  8:  Requirements  for 
Displayed  Colon 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  9:  Requirements  for 
Non-Keyboard  Input  Devices 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  10:  Dialogue 
Principles 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  11:  Usability 
Statements 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  12:  Presentation  of 
Information 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  13:  User  Guidance 
Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  14:  Menu  Dialogues 
Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  15:  Command 
Dialogues 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals.  Part  16:  Direct 
Manipulation  Dialogues 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  17:  Form-Riling 
Dialogues 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  18:  Question  and 
Answer  Dialogues  (not  yet  started) 

Ergonomic  Requirements  for  Office  Work  with  Visual  Display  Terminals,  Part  19:  Natural 
language  Dialogues  (not  yet  started) 

Information  Technology  -  Identification  of  Picture  Coding  Methods,  Part  1:  Identification. 
August  1990 

Information  Technology  -  Identification  of  Picture  Coding  Methods.  Part  2:  Procedure  for 
Registration,  August  1990 

Information  Technology  •  Coded  Representation  of  Pictures,  Part  1:  Encoding  Principles  for 
Picture  Representation  in  a  7-  or  8-Bit  Environment,  September  1988 

Information  Technology  -  Coded  Representation  of  Pictures,  Part  2:  Encoding  Principles  for 
Photographic  Images,  May  1992 

Information  Technology  -  Guidelines  for  the  Management  of  Software  Documentation,  Technical 
Report  Type  3.  1990 

Information  Processing  Systems-  Fiber  Distributed  Data  Interface  (FDDI),  Part  1:  Token  Ring 
Physical  Layer  Protocol  (PHY),  1989 

Information  Processing  Systems-  Fiber  Distributed  Data  Interface  (FDDI),  Part  2:  Token  Ring 
Media  Access  Control  (MAC),  1989 

Information  Technology-  Fiber  Distributed  Data  Interface  (FDDI),  Part  3:  Physical  Layer  Medium 
Dependent  (PMD),  August  1990 

Information  Technology  -  Fiber  Distributed  Data  Interface  (FDDI),  Part  4:  Single  Mode 
Fiber/Physical  Layer  Medium  Dependent  Physical  Connectors  (SMF-PMD),  1993 
Information  Technology  -  Fiber  Distributed  Data  Interface  (FDDI),  Part  5:  Hybrid  Ring  Control 
(HRC),  1993 
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UNCLASSIFIED 


CD  9314-6 

ISO  9316 
DIS  9318-1 

ISO  9318-2 

ISO  9318-3 

ISO  9318-4 

DIS  9324 
ISO  9496 

ISO  9306-1 

ISO  9506-1  AD  1 
ISO  9506-2 

ISO  9506-2  ADI 
ISO  9506-3 

ISO  9306-4 

ISCVIEC  9541-1 
ISO/IEC  9541-1/Cor  1 
ISO/IEC  9541-2 
MS  9541-3 

MS  9541-4 

MS  9541-5 

MS  9541-6 

DP  9541-7 

ISO  9542* 

ISO  9542  PDAM  1 
ISO  9543* 

ISQ/TR  9544 
ISO/IEC  9545* 

ISO/TR  9547 

ISO  9548* 

ISO/IEC  9548-2 

ISO  9549* 

ISO  9564-1 

ISO  9564-2 

ISO/IEC  TR  9571* 
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Information  Technology  -  Fiber  Distributed  Data  Interface  (FDDI),  Part  6:  Station  Management 
(SMT)  Standard,  1993 

Information  Processing  Systems  -  Small  Computer  System  Interface  (SCSI),  1989 

Information  Processing  Systems  -  Intelligent  Peripheral  Interface,  Part  1:  Physical  Level,  August 

1987 

Information  Processing  Systems  -  Intelligent  Peripheral  Interface,  Part  2:  Device  Specific 
Command  Set  for  Magnetic  Disk  Drives,  1990  (AN SI/1  SO  9318-2-1990) 

Information  Processing  Systems  -  Intelligent  Peripheral  Interface,  Part  3:  Device  Generic 
Command  Set  for  Magnetic  and  Optical  Disk  Drives,  1990  (ANSI/ISO  9318-3-1990) 

Information  Processing  Systems  -  Intelligent  Peripheral  Interface,  Part  4:  Device  Generic 
Command  Set  for  Magnetic  Tape  Drives,  1990  (ANSI/ISO  9318-4-1990) 

Information  Processing  -  Storage  Module  Interfaces,  September  1988 

Information  Processing  -  Programming  Languages  -  Ceil  1  High  Level  Language  (CHILL), 
August  1989  (Z.200) 

Industrial  Automation  Systems  -  Manufacturing  Message  Specification,  Part  1:  Service  Definition, 
1990 

Amendment  1:  Data  Exchange,  1993 

Industrial  Automation  Systems  -  Manufacturing  Message  Specification,  Part  2:  Protocol 

Specification,  1990 

Amendment  1:  Data  Exchange,  1993 

Industrial  Automation  Systems  -  Manufacturing  Message  Specification,  Part  3:  Companion 
Standard  for  Robotics,  1991 

Industrial  Automation  Systems  -  Manufacturing  Message  Specification,  Part  4:  Companion 
Standard  for  Numerical  Control,  1992 

Information  Technology  -  Font  Information  Exchange,  Part  1:  Architecture,  May  1991 
Technical  Corrigendum  1,  1992 

Information  Technology  -  Font  Information  Exchange.  Part  2:  Interchange  Format,  May  1991 
Information  Technology  -  Font  and  Character  Information  Exchange,  Part  3:  Character 
Identification  Method,  October  1991 

Information  Processing  Systems-  Font  and  Character  Information  Exchange,  Part  4:  Character 
Collections,  December  1987 

Information  Processing  Systems-  Font  and  Character  Information  Exchange,  Part  5:  Font 
Attributes  and  Character  Model.  December  1987 

Information  Processing  Systems-  Font  and  Character  Information  Exchange.  Part  6:  Font  and 
Character  Attribute  Subsets  and  Application,  December  1987 

Information  Processing  Systems-  Font  and  Character  Information  Exchange,  Part  7:  Font 
Interchange  Format,  May  1987 

Information  Processing  Systems-  Telecommunications  and  Information  Exchange  Between 
Systems  -  End  System  to  Intermediate  System  Routing  Exchange  Protocol  for  Use  in  Conjunction 
with  the  Protocol  for  Providing  the  Connectionless-Mode  Network  Service  (ISO  8473),  1988 
(Revised  Edition,  1989) 

Amendment  1:  Dynamic  Discovery  of  OSI NSAP  Addresses  by  End  Systems  (New  Wosk  Item) 
Information  Proceuing  Systems  •  Information  Exchange  Between  Systems  -  Synchronous 
Transmission  Signal  Quality  at  DTE/DCE  Interfaces,  May  1989 
Information  Processing  -  Computer-Assisted  Publishing  -  Vocabulary.  December  1988 
Information  Technology  •  Open  Systems  Interconnection  -  Application  Layer  Structure  (ALS), 
Edition  2  (incorporates  AM  1  and  AM  2),  December  1993 

Programming  Language  Processors  •  Test  Methods  -  Guidelines  for  Their  Development  and 
Acceptability,  April  1988 

Information  Technology  -  Open  Systems  Interconnection  •  Session  Connection  leu  Protocol  to 
Provide  the  Conoectionleu-Mode  Session  Service,  August  1989  (held  pending  publication  of  ISO 
8326  and  8327:1)  (X.235) 

Information  Technology  •  Open  Systems  Interconnection  -  Session  Con  need  ooleu  Protocol  to 
Provide  the  Connectionless-Mode  Seuion  Service,  Part  2:  PICS  Proforma,  April  1993 
(SC21  N  7679]  (approved  for  IS  in  October  1993:  initiation  of  ITU-TS  approval  ballot  expected 
February  1994)  (X.255) 

Information  Technology  •  Galvanic  Isolation  of  Balanced  Interchange  Circuit,  October  1990 
Financial  Transactions  -  Retail  Banking  Security  •  Personal  Identification  Number  (PIN) 
Management  and  Security,  Part  1:  PIN  Protection  Principles  and  Techniques,  TC68/SC6/WG6 
Financial  Transactions  •  Retail  Banking  Security  •  Personal  Identification  Number  (PIN) 
Management  and  Security,  Part  2:  Approved  Algorithms  for  PIN  Encipherment,  TC68/SC6/WG6 
Information  Technology  •  Open  Systems  Interconnection  -  LOTOS  Description  of  the  Session 
Service,  September  1989  (TR  has  been  cancelled  now  that  the  Edition  2  of  Sessioo  Service  has  beau 
published) 
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UNCLASSIFIED 


1SQABC1R9S72* 

WDIR  9573-1 
WDTR  9573-2 
WDIR  9573-3 
WDIR  9573-4 
WDTO  9573-5 
WDTR  9573-6 
WDTR  9573-7 
WDTR  9573-9 
WDTR  9573-9 
WDTR  9573-10 
ISCMEC  TR  9573-11 
1SCVIEC  TR  9573-12 
ISCMEC  TR  9573-13 
WDTR  9573-14 
WDTR  9573-15 
WDTR  9573-16 
ISCMEC  9574* 

ISCMEC  9574  DAM  1 
ISCMEC  TR  9575* 
ISCMEC  9576* 

DIS  9576-2* 

ISCMEC  TR  9577* 
ISCMEC  TR  9578 
ISO  9579-1* 

ISO  9579-1 WDAM1 

ISO  9579-2* 

ISO  9579-2  PD  AM  1 
ISO  9579-2  WDAM  2 

CD  9579-3 

ISO  9592-1 

ISO  9592-1  AMI 
190  9592-2 


Information  Technology  -  Open  System*  Interconnection  -  LOTOS  Description  of  the  Session 
Protocol,  September  1989  (TR  bss  been  ctncelled  now  tbet  the  Edition  2  of  Session  Service  has 
been  published) 

Information  Processing  •  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  1:  SGML 
Tutorial,  December  1988 

Information  Processing  •  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  2:  Basic 
Technique,  December  1988 

Information  Processing  •  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  3:  Advanced 
Techniques  -  Using  LINK  and  CONCUR,  December  1988 

Information  Processing  -  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  4:  Advanced 
Techniques  -  Using  SHORTREF  to  Indicate  Markup,  December  1988 

Information  Processing  -  SGML  Support  Facilities  •  Techniques  for  Using  SGML,  Part  5:  Using 
Non-Latin  Alphabets,  December  1988 

Information  Processing  -  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  6: 
Referencing  and  Synchronization,  December  1988 

Information  Processing  -  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  7: 
Mathematics  and  Chemistry,  December  1988 

Information  Processing  -  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  8:  Tables, 
December  1988 

Information  Processing  •  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  9:  Using 
SGML  for  Computer  to  Computer  Interchange,  December  1988 

Information  Processing  -  SGML  Support  Facilities  -  Technique*  for  Using  SGML,  Part  10: 
Designing  Applications  for  Database  Interfacing,  December  1988 

Information  Technology  -  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  11: 
Application  at  ISO  Central  Secretariat  for  International  Standards  and  Technical  Reports,  1992 
Information  Technology  -  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  12:  Public 
Entity  Sets  for  General  and  Publishing  Symbols,  1991 

Information  Technology  -  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  13:  Public 
Entity  Sets  for  Mathematics  and  Srienre.  June  1991 

Information  Processing  -  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  14:  Public 
Entity  Set*  for  Latin  Baaed  Alphabets,  December  1988 

Information  Processing  -  SGML  Support  Facilities  .  Techniques  for  Using  SGML,  Part  IS:  Public 
Entity  Sets  for  Non-Latin  Based  Alphabet*.  December  1988 

Information  Processing  -  SGML  Support  Facilities  -  Techniques  for  Using  SGML,  Part  16:  Public 
Entity  Sea  for  Ideograms,  December  1968 

Information  Technology  .  Provision  of  the  OSI  Connection-Mode  Network  Service  (CONS)  by 
Packet  Mode  Terminal  Equipment  Connected  to  an  Integrated  Services  Digital  Network  (ISDN), 
Edition  2.  1992 

Amendment  1:  Provision  of  the  CONS  on  an  ISDN  Circuit-Switch  Channel  Connecting  Directly  to 
the  Remote  Terminal,  April  1991 

Information  Technology  -  Telecommunicatinns  and  Information  Exchange  Between  Systems  -  OSI 
Routing  Framework,  June  1990 

Information  Technology  -  Open  Systems  Interconnection  -  Connectionless  Presentation  Protocol 
Specification,  1991  (X.236) 

Information  Technology  -  Open  Systems  Interconnection  -  Presentation  Protocol  to  Provide  the 
Connectionless-Mode  Presentation  Service,  Part  2:  PICS  Proforma  for  Connectionless 
Presentation  Protocol,  July  1991  [SC21  N  5930]  (IS  text  expected  March  1994)  (X. 256) 

Protocol  Identification  in  the  OSI  Network  Layer,  1993 

Communicatioo  Interface  Connectors  Used  in  Local  Area  Networks,  May  1990 

Information  Technology  -  Database  Languages  -  Remote  Database  Access  (RDA)  -  Part  1:  Generic 

Model,  Service  and  Protocol  March  1993  (SC21  N  7689] 

Amendment  1:  Generic  RDA,  August  1992  [SC21  N  7202]  (PDAM  expected  July  1994;  DAM 
July  1995;  AM  July  1996]) 

Information  Technology  -  Database  Languages  -  Remote  Database  Access  (RDA)  -  Part  2:  SQL 
Specialization,  March  1993  [SC21  N  7703) 

Amendment  1:  Support  for  SQL  1992,  September  t993  [SC21  N  8307] 

Amendment  2:  RDA  Support  for  Stored  DBL  Statements.  October  1990  [SC21  N  5138]  (rapporteur 
meeting  January  1994;  PDAM  expected  July  1995) 

Information  Technology  •  Database  Languages  •  Remote  Database  Access  (RDA)  -  Part  3:  SQL 
PICS  Proforma,  October  1993  [SC21  N  8067]  (editing  meeting  January  1994) 

Information  Technology  -  Computer  Graphics  -  Programmer's  Hierarchical  Interactive  Graphics 
System  (FHK3S),  Part  1:  Functional  Description,  May  1989  (ANSI/ISO  9592-1-1989) 

Amendment  1:  PHIGS  Plat  Support,  1992  (ANSIASO  9592-la-1992) 

Information  Technology  •  Computer  Graphics  -  Programmer's  Hierarchical  Interactive  Graphics 
System  (PUGS),  Part  2:  Archive  File  Formal  May  1969  (ANSWSO  9592-2-1969) 
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ISO  9592-2  AM  1  Amendment  1:  PHIGS  Plus  Support,  September  1992  (ANSI/ISO  9592-2*- 1992) 

ISO  9592-3  Information  Technology  -  Computer  Graphics  -  Programmer's  Hierarchical  Interactive  Graphics 

System  (PHIGS),  Part  3:  Clear-Test  Encoding  of  Archive  File,  May  1989  (ANSI/ISO  9592-3-1989) 
ISO  9592-4  Information  Technology  -  Computer  Graphics  -  Programmer's  Hierarchical  Interactive  Graphic* 

System  (PHIGS),  Part  4:  Plus  Lumiere  und  Surfaces  (PHIGS  Plus),  1992  (ANSI/ISO  9592-4-1992) 
ISO/IEC  9593-1  Information  Technology  -  Computer  Graphics  -  Programmer's  Hierarchical  Interactive  Graphics 
System  (PHIGS)  Language  Bindings.  Pvt  I:  FORTRAN,  August  1990  (ANSI/ISO  9593.1-1992) 

DIS  9593-2  Information  Technology  -  Computer  Graphics  -  Programmer's  Hierarchical  Interactive  Graphics 

System  (PHIGS)  Language  Bindings,  Part  2:  Extended  Pascal  (awaiting  DIS  ballot) 

ISO/IEC  9593-3  Information  Technology  -  Computer  Graphics  -  Programmer's  Hierarchical  Interactive  Graphics 
System  (PHIGS)  Language  Bindings,  Part  3:  Ada,  July  1990  (ANSI/ISO  95933-1990) 

ISO/IEC  9593-3  DAM  1  Amendment  1:  Incorporation  of  PHIGS  Plus 

ISO/IEC  9593-4  Information  Technology  -  Computer  Graphics  -  Programmer'*  Hierarchical  Interactive  Graphics 
System  (PHIGS)  Language  Bindings,  Part  4:  C.  1991  (ANSI/ISO  9593.4-1991) 

ISO/IEC  9594-1*  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  1:  Overview  of 
Concepts,  Models  and  Services,  December  1990  (X300:1988) 

ISO/IEC  9594- 1  AM  1*  Amendment  1:  Replication,  Schema  and  Access  Control,  January  1992  [SC21  N  6502) 
(successfully  passed  ballot  September  1992) 

ISO/IEC  9594-1/9  WDAMi  Amendments  to  Parts  1  to  9  on  Internationalization  of  the  Directory  Enhancement  of 
Directory,  1993  (NWI  proposal)  [JTC1  N  2039] 

ISO/IEC  9594-1/9  WDAMs  Amendments  to  Parts  1  to  9  on  Enhancement  of  Directory  Operational  Security,  1993  (NWI 
proposal)  [JTC1  N  2248] 

ISO/IEC  9594-1/9  WDAMs  Amendments  to  Parts  1  to  9  on  Directory  Schema  Migration,  1993  (NWI  proposal)  [SC21  N 
7942] 

DIS  9594-1.2  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  1:  Overview  of 

Concepts,  Models  and  Services,  Edition  2  (incorporates  AMI),  1993  (ITU-TS  ballot  closed 
November  1993)  (X. 500:1993) 

ISO/IEC  9594-2*  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  2:  Models. 

December  1990  (X.S01:1988) 

ISO/IEC  9594-2/Cor  1  Technical  Corrigendum  1,  1991 
ISO/IEC  9594-2/Cor  2  Technical  Corrigendum  2,  July  1992 

ISO/IEC  9594-2  AM  1*  Amendment  1:  Access  Control.  January  1992  [SC21  N  6502]  (successfully  passed  ballot 
September  1992) 

ISO/IEC  9594-2  AM  2  Amendment  2:  Schema  Extensions,  January  1992  [SC 21  N  6503]  (successfully  passed  ballot 
September  1992) 

ISO/IEC  9594-2  AM  3  Amendment  3:  Replication,  January  1992  [SC21  N  6504]  (successfully  passed  ballot 
September  1992) 

DIS  9594-2.2  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory.  Part  2:  Models. 

Edition  2  (incorporates  AMI,  AM2,  and  AM3),  1993  (ITU-TS  ballot  closed  November  1993) 
(X.501:1993) 

ISO/IEC  9594-3*  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  3:  Abstract  Service 
Definition.  December  1990  (X.3U:1988) 

ISO/IEC  9594-3/Cor  1  Technical  Corrigendum  1,  December  1991 
ISO/IEC  9594-3/Cor  2  Technical  Corrigendum  2,  July  1992 
ISO/IEC  9594-3/Cor  3  Technical  Corrigendum  3.  October  1992 
ISO/IEC  9594-3/Cor  4  Technical  Corrigendum  4,  March  1993 

ISO/IEC  9594-3  AM  1*  Amendment  1:  Access  Control,  January  1992  [SC21  N  6505)  (successfully  passed  ballot 
September  1992) 

ISO/IEC  9594-3  AM  2  Amendment  2:  Replication,  Schema  and  Enhanced  Search.  January  1992  [SC21  N  6506] 
(successfully  passed  ballot  in  September  1992) 

DIS  9594-3.2  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  3:  Abstract  Service 

Definition,  Edition  2  (incorporates  AMI  and  Am2),  1993  (ITU-TS  ballot  closed  November  1993) 
(X.51 1:1993) 

ISO/IEC  9594-4*  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  4:  Procedures  for 
Distributed  Operations,  December  1990  (X.518:!988) 

ISO/IEC  9594-4/Cor  1  Technical  Corrigendum  1,  December  1991 
ISO/IEC  9594-4/Cor  2  Technical  Corrigendum  2.  July  1992 
ISO/IEC  9594-4/Cor  3  Technical  Corrigendum  3.  March  1993 

ISO/IEC  9594-4  AM  1  ♦  Amendment  1:  Access  Control,  January  1992  [SC 21  N  6507]  (successfully  passed  ballot 
September  1992) 

ISO/IEC  9594-4  AM  2  Amendment  2:  Replication,  Schema  and  Enhanced  Search,  January  1992  [SC 21  N  6508] 
(successfully  passed  ballot  in  September  1992) 

DIS  9594-4.2  Information  Technology  •  Open  Systems  Interconnection  •  The  Directory,  Part  4:  Procedures  for 

Distributed  Operations,  Edition  2  (incorporates  AMI  and  AM2),  1993  (ITU-TS  ballot  closed 
November  1993)  (X.518:1993) 
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ISO/IBC  9594-Se  Information  Technology  -  Open  Syitenu  Interconnection  -  The  Directory,  Pvt  S:  Protocol 
Specification!,  December  1990  (X .519:19*8) 

ISO/IEC  9594-5/Cor  1  Technical  Conigeodum  1.  October  1992 

ISO/IEC  9594-5  AM  1*  Amendment  1:  Replication,  2  January  1992  [SC21  N  6509]  (approved  5  September  1992) 

DiS  9594-5.2  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  5:  Protocol 

Specifications,  Edition  2  (incorporates  AMI),  1993  (ITU-TS  ballot  closed  November  1993) 
(X.519:1993) 

ISO/IEC  9594-6*  Information  Technology  •  Open  Systems  Interconnection  -  The  Directory,  Part  6:  Selected  Attribute 
Types,  December  1990  (X. 520: 1988) 

ISCMEC  9594-6  AM  1*  Amendment  1:  Schema  Extensions,  2  January  1992  (SC21  N  6510]  (approved  5  September 
1992) 

DIS  9594-6.2  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  6:  Selected  Attribute 

Types,  Edition  2  (incorporates  AMI),  1993  (ITU-TS  ballot  closed  November  1993)  (X .5 20: 1993) 
ISO/IEC  9594-7*  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  7:  Selected  Object 
Classes,  December  1990  (XJ21:1988) 

ISO/IEC  9594-7/Cor  1  Technical  Corrigendum  1,  December  1991 
ISO/IEC  9594-7/Cor  2  Technical  Corrigendum  2,  July  1992 

ISO/IEC  9594-7  AM  1*  Amendment  1:  Schema  Extensions,  2  January  1992  [SC21  N  6511]  (approved  5  September 
1992) 

IMS  9594-7.2  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  7:  Selected  Object 

Classes,  Edition  2  (incorporates  AMI).  1993  (ITU-TS  ballot  closed  November  1993)  (X.521:1993) 
ISO/IEC  9594-8*  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  8:  Authentication 
Framework,  December  1990  (X .509) 

ISO/IEC  9594-8/Cor  1  Technical  Corrigendum  1,  1991 

ISO/IEC  9594-8  AM  1*  Amendment  1:  Access  Control,  2  January  1992  [SC21  N  6512]  (approved  5  September  1992) 
ISO/IEC  9594-8  WDAM  Amendment  on  Security  Enhancement  to  Directory  (Extensions  for  Certificate  Definitions)  (NWI 
proposal  accepted  April  1993;  PDAM  expected  July  1995) 

DIS  9594-8.2  Information  Technology  -  Open  Systems  Interconnection  •  The  Directory,  Part  8:  Authentication 

Framework,  Edition  2  (incorporates  AMI),  1993  (ITU-TS  ballot  closed  November  1993) 
(X.309:1993) 

ISO/IEC  9594-9*  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  9:  Replication, 
January  1992  [SC21  N  6513]  (ITU-TS  ballot  closed  November  1993)  (X.525:1993) 

CD  9594-10*  Information  Technology  •  Open  Systems  Interconnection  -  The  Directory,  Part  10:  PICS  Proforma, 

for  the  OS1  Directory  DUA  Protocol.  1993  (fast-track  ballot  requested)  (X.58 1:1992) 

WD  9594-11  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  1 1 :  PICS  Proforma, 

for  the  OSI  Directory  DSA  Protocol,  1993  (fast-trade  ballot  requested)  (X. 582: 1992) 

WD  9594-w  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory,  Part  x:  Use  of  Systems 

Management  for  Administration  of  the  Directory,  June  1993  [SC21  N  7930]  (CD  expected 
July  1994] 

ISO/IEC  9595*  Information  Technology  -  Open  Systems  Interconnection  -  Common  Management  Information 

Service  (CMIS)  Definition.  Edition  2  (incorporates  ADI  and  AD  2).  April  1991  (X.710:1991) 
ISO/IEC  9595/Cor  1  Technical  Corrigendum  1,  April  1992  [SC21  N  8166] 

ISO/IEC  9595/Cor  2  Technical  Corrigendum  2,  July  1992 

ISO/IEC  9595  PDAM  3  Amendments:  Support  of  Allomorphism,  26  November  1990  [SC21  N  4966]  (SC21  has  asked 
JTC1  for  endorsement  to  cancel  this  project) 

ISO/IEC  9595  AM  4  Amendment  4:  Access  Control,  July  1992 

ISO/IEC  9595  WDAM  5  Amendment  5:  Enhanced  Functionality  for  System  Management  Communications,  June  1993 
(expected  to  become  Edition  3  of  ISO  9595;  PDAM  expected  December  1994) 

ISO/IEC  9596-1 ♦  Information  Technology  -  Open  Systems  Interconnection  -  Common  Management  Information 
Protocol  (CMIP),  Part  1:  Specification,  Edition  2  (incorporates  ADI  and  AD  2  of  ISO  9596:1990), 
April  1991  (X.711:1991) 

ISO/IEC  9596-1/Cor  1  Technical  Corrigendum  1,  April  1992 
ISO/IEC  9596-1/Cor  2  Technical  Corrigeodum  2,  July  1992 
ISO/IEC  9596-1/Cor  3  Technical  Corrigendum  3,  September  1992 
ISO/IEC  9596-l/Cor  4  Techticel  Corrigendum  3.  Msrch  1993 

ISO/IEC  9596  PDAM  3  Amendment  3:  Support  of  Allomorphism,  July  1990  [SC21  N  4967]  [JTC1  N  761]  (SC21  has 
asked  JTC1  for  endorsement  to  cancel  this  project) 

ISO/IEC  9596  PDAM  4  Amendment  4:  State  Table,  January  1990  [SC21  N  4058]  (new  work  item  June  1990;  terminated 
June  1991) 

ISO/IBC  9596  WDAM  5  Amendment  5:  Enhanced  Functionality,  June  1993  [SC21  N  7970]  (PDAM  expected 
December  1994) 

ISO/IEC  9596-2*  Information  Technology  -  Open  Systems  Interconnection  -  Common  Management  Information 
Protocol  (CMIP)  Specification,  P«t  2:  PICS  Proforma.  21  July  1992  [SC21  N  7111]  (X.712) 
ISO/IEC  9596-2/Cor  1  Technical  Corrigeodum  1,  June  1993 
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ISCVIEC  9636-1  Information  Technology  -  Computer  Graphic*  -  Interfacing  Technique*  for  Dialogue*  with  Graphical 
Devices  -  Functional  Specification  (CGI).  Part  1:  Overview,  Profiles,  and  Conformance,  May  1991 
(ANSI/ISO  9636-1-1991) 

ISCVTEC  9636-2  Information  Technology  -  Computer  Graphic*  -  Interfacing  Technique*  for  Dialogues  with  Graphical 
Devices  -  Functional  Specification  (CGI),  Part  2:  Control,  Negotiation,  and  Errors,  May  1991 
(ANSI/ISO  9636-2-1991) 

ISCVIEC  9636-3  Information  Technology  •  Computer  Graphics  -  Interfacing  Techniques  for  Dialogues  with  Graphical 
Devices  -  Functional  Specification  (CGI),  Part  3:  Output  and  Attributes,  May  1991  (ANSI/ISO 
9636-3-1991) 

ISCVIEC  9636-4  Information  Technology  -  Computer  Graphics  -  Interfacing  Techniques  for  Dialogues  with  Graphical 
Devices  •  Functional  Specification  (CGI),  Part  4:  Segmentation,  May  1991  (ANSI/ISO  9636-4- 
1991) 

ISCVIEC  9636-3  Information  Technology  •  Computer  Graphics  -  Interfacing  Techniques  for  Dialogues  with  Graphical 
Devices  -  Functional  Specification  (CGI),  Part  3:  Input  and  Echoing,  May  1991  (ANSI/ISO  9636-3- 
1991) 

ISCVIEC  9636-6  Information  Technology  -  Computer  Graphics  -  Interfacing  Techniques  for  Dialogues  with  Graphical 
Devices  -  Functional  Specification  (CGI),  Part  6:  Raster,  May  1991  (ANSI/ISO  9636-6-1991) 

WD  9636-8  Information  Technology  -  Computer  Graphics  -  Interfacing  Techniques  for  Dialogues  with  Graphical 

Devices  -  Functional  Specification  (CGI),  Part  8:  FORTRAN  Language  Binding  of  CGI,  1989 
WD  9636-11  Information  Technology  -  Computer  Graphics  -  Interfacing  Techniques  for  Dialogues  with  Graphical 

Devices  -  Functional  Specification  (CGI),  Part  11:  C  Language  Binding  of  CGI.  1989 
IMS  9637-1  Information  Technology  -  Computer  Graphics  -  Interfacing  Techniques  for  Dialogues  with  Graphical 

Device*  -  Functional  Specification  (CGI)  -  Data  Stream  Binding,  Part  1:  Character  Encoding  (review 
period  ends  19  November  1991) 

ISO/IEC  9637-2  Information  Technology  -  Computer  Graphics  -  Interfacing  Techniques  for  Dialogues  with  Graphical 
Devices  -  Functional  Specification  (CGI)  -  Data  Stream  Binding,  Part  2:  Binary  Encoding.  1992 
IMS  9637-3  Information  Technology  -  Computer  Graphics  -  Interfacing  Techniques  for  Dialogues  with  Graphical 

Devices  -  Functional  Specification  (CGI)  -  Data  Stream  Binding,  Part  3:  Clear  Text  Encoding 
IMS  9638-1  Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Language  Bindings,  Part  1: 

FORTRAN 

US  9638-2  Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Language  Bindings,  Part  2:  Pascal 

US  9638-3  Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Language  Bindings,  Part  3:  Ada 

US  9638-4  Interface  Techniques  for  Dialogues  with  Graphical  Devices  -  CGI  Language  Bindings,  Part  4:  C 

(review  period  end*  10  September  1991) 

ISO/IEC  9646-1*  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Testing  Methodology  and 
Framework,  Part  1:  General  Concepts,  July  1991  [SC21  N  3863]  (X.290) 

ISO/IEC  9646-1  Cor  1  Technical  Corrigendum  1,  October  1993  [SC21  N  8293] 

ISO/IEC  9646-1  AM  1  Amendment  1:  Protocol  Profile  and  Multi-Protocol  Testing,  October  1993 
ISO/IEC  9646-1  AM  2  Amendment  2:  Multi-Party  Testing  Methodology,  October  1993 

D1S  9646-1.2  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Testing  Methodology  and 

Framework,  Part  1:  General  Concepts,  Edition  2  (incorporates  AMI  and  AM2)  (IS  text  expected 
March  1994)  (X.290) 

ISO/IEC  9646-2*  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Testing  Methodology  and 
Framework,  Part  2:  Abstract  Test  Suite  Specification  (Excluding  Annexes  E  and  F  on  TTCN), 
May  1991  [SC21  N  3867]  (X.291) 

ISO/IEC  9646-2  Annex  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Testing  Methodology 
and  Framework,  Part  2:  Abstract  Test  Suite  Specification,  Annex:  Guidelines  for  PICS  Proformas 
(SC6  N  6243] 

ISO/IEC  9646-2  AM  1  Amendment  1:  Protocol  Profile  and  Multi-Protocol  Testing,  October  1993 
ISOAEC  9646-2  AM  2  Amendment  2:  Multi-Party  Testing  Methodology,  October  1993 

DIS  9646-2.2  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Testing  Methodology  and 

Framework,  Part  2:  Abstract  Test  Suite  Specification,  Edition  2  (X.291) 

ISO/IEC  9646-3*  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Testing  Methodology  and 
Framework,  Part  3:  The  Tree  and  Tabular  Combined  Notation  (TTCN),  October  1992  (X.292) 
ISO/IEC  9646-3  AM  1  Addendum  1:  TTCN  Extensions,  October  1993 

ISO/IEC  9646-3  DAM  2  Amendment  2:  Further  TTCN  Extensions,  December  1993  [SC2I  N  8374] 

ISO/IEC  9646-4*  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Testing  Methodology  and 
Framework,  Part  4:  Test  Realization,  July  1991  (X.293) 

ISO/IEC  9646-4  AM  1  Amendment  1:  Protocol  Profile  and  Multi-Protocol  Testing,  October  1993  [SC21  N  7323] 

ISO/IEC  9646-4  AM  2  Amendment  2:  Multi-Party  Testing  Methodology,  October  1993  [SC21  N  7326] 

DIS  9646-4.2  Information  Technology  -  Open  Systems  Interconnection  •  Conformance  Testing  Methodology  and 

Framework,  Part  4:  Test  Realization,  Edition  2,  1993  (X.293) 

ISO/IEC  9646-3*  Information  Technology  -  Open  Systems  Interconnection  •  Conformance  Testing  Methodology  and 
Framework,  Part  3:  Requirements  on  Test  Laboratories  and  Clients  for  the  Conformance 
Assessment  Process,  July  1991  (X.294) 
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ISO/IEC  9646-5  Cor  1  Technical  Corrigendum  1,  October  1993  [SC21  N  8294) 

ISO/IEC  9646-5  AM  1  Amendment  1:  Protocol  Profile  and  Multi-Protocol  Testing,  October  1993 
ISOAEC  9646-5  AM  2  Amendment  2:  Multi-Party  Testing  Methodology,  October  1993 

DIS  9646-5.2  Information  Technology  -  Open  Systems  Interconnection  •  Conformance  Testing  Methodology  and 

Framework,  Part  5:  Requirements  on  Test  Laboratories  and  Clients  for  the  Conformance 
Assessment  Process,  Edition  2.  1993  (X.294) 

ISO/IEC  9646-6  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Testing  Methodology  and 
Framework,  Part  6:  Protocol  Profile  Test  Specification,  1993  [SC21  N  7329]  (editing  meeting 
September  1993;  IS  text  expected  March  1994)  (X.295) 

DIS  9646-7  Information  Technology  -  Open  Systems  Interconnection  •  Conformance  Testing  Methodology  and 

Framework,  Part  7:  Requirements  and  Guidelines  on  Implementation  Conformance  Statement  (ICS) 
and  ICS  Proformas,  October  1993  [SC21  N  8180]  (editing  meeting  July  1994) 

ISO  9660  Information  Processing  -  Volume  and  File  Structure  of  CD-ROM  for  Information  Exchange, 

April  1988 

ISO  9735  Electronic  Data  Interchange  for  Administration,  Commerce  and  Transport  (EDIFACT)  -  Application 

Level  Syntax  Rules,  July  1988  (amended  and  reprinted  in  1990) 

ISO  9735  AM  1  Amendment  1,  1992 

TR  9789  Information  Technology  -  Guidelines  for  the  Organization  and  Representation  of  Data  Elements  for 

Data  Interchange  -  Coding  Methods  and  Principles,  November  1993 
ISO/IEC  9796  Information  Technology  -  Security  Techniques  -  Digital  Signature  Scheme  Giving  Message 

Recovery,  1991 

ISO/IEC  9797  Information  Technology  -  Data  Cryptographic  Techniques  -  Data  Integrity  Mechanism  Using  a 

Cryptographic  Check  Function  Employing  a  Block  Cipher  Algorithm.  1989 
ISO/IEC  9798-1  Information  Processing  -  Security  Techniques  -  Entity  Authentication  Mechanisms,  Part  1:  General 
Model,  1991 

DIS  9798-2  Information  Technology  -  Security  Techniques  -  Entity  Authentication  Mechanisms,  Part  2:  Entity 

Authentication  Using  Symmetric  Techniques,  SC27/WG2,  1993 
DIS  9798-3  Information  Technology  -  Security  Techniques  -  Entity  Authentication  Mechanisms,  Part  3:  Entity 

Authentication  Using  a  Public  Key  Algorithm,  SC27/WG2,  1993 
WD  9798-4  Information  Technology  -  Security  Techniques  -  Entity  Authentication  Mechanisms,  Part  4:  Entity 

Authentication  Using  Non-Revenible  Functions,  SC27/WG2,  1993 
WD  9798-x  Information  Technology  -  Security  Techniques  -  Entity  Authentication  Mechanisms,  Part  x:  Entity 

Authentication  Using  Zero-Knowledge  Techniques,  SC27/WG2, 1993 
ISO/IEC  9804*  Information  Technology  -  Open  Systems  Interconnection  -  Service  Definition  for  the  Commitment. 

Concurrency,  and  Recovery  (CCR)  Service  Element,  November  1990  (X.851:1993) 

ISO/IEC  9804/Cor  1  Technical  Corrigendum  1,  December  1991 

ISO/IEC  9804  PD  AM  U  Amendment  1:  Enhancements,  July  1992  [SC21  N  7246]  (DIS  text  expected  June  1994  and  IS 
expected  June  1995) 

ISO/IEC  9804  AM  2  Amendment  2:  Session  Mapping  Changes  (Additional  Synchronization  Functionality), 
December  1992  [SC21  N  7278] 

ISO/IBC  9804  WDAM  3  Amendment  3:  Restart  (SC21  has  asked  JTC1  for  endorsement  to  cancel  the  project)) 

DIS  9804.2  Information  Technology  -  Open  Systems  Interconnection  -  Service  Definition  for  the  Commitment, 

Concurrency,  and  Recovery  (CCR)  Service  Element,  Edition  2  (incorporates  AM  1  and  AM  2), 
January  1993  (SC21  N  7659]  (ballot  closed  November  1993) 

ISO/IEC  9805*  Information  Technology  -  Open  Systems  Interconnection  •  Protocol  Specification  for  the 

Commitment,  Concurrency,  and  Recovery  (CCR)  Service,  November  1990  (X.247) 

ISO/IEC  9805/Cor  1  Technical  Corrigendum  1,  December  1991 
ISO/IEC  9805/Cor  2  Technical  Corrigendum  2,  December  1992 

ISO/IEC  9805  PD  AM  12  Amendment  1:  Enhancements,  July  1992  [SC21  N  7247]  (DIS  text  expected  June  1994.  IS  text 

June  1995) 

ISOAEC  9805  AM  2  Amendment  2:  Session  Mapping  Changes  (Additional  Synchronization  Functionality), 
December  1992  [SC21  N  7279] 

ISO/IEC  9805  WDAM  3  Amendment  3:  Restart  (SC21  has  asked  JTC1  for  endorsement  to  cancel  project) 

ISO/IEC  9805-1  Information  Technology  -  Open  Systems  Interconnection  •  Protocol  Specification  for  the 
Commitment,  Concurrency,  and  Recovery  (CCR)  Protocol,  Edition  2,  1993  [SC21  N  8433] 
(X  .852: 1993) 

DIS  9805-2.2*  Information  Technology  -  Open  Systems  Interconnection  •  Protocol  Specification  for  the 

Commitment,  Concurrency,  and  Recovery  (CCR)  Protocol,  Part  2:  CCR  PICS  Proforma,  September 
1993  (IS  expected  September  1994)  (X.853:1993) 

ISO  9807  Financial  Transactions  -  Retail  Banking  Security  -  Requirement!  for  Message  Authentication, 

TC68/SC6/WG6 

ISO/IEC  9834-1*  Information  Technology  -  Open  Systems  Interconnection  -  Procedures  for  the  Operation  of  OSI 
Registration  Authorities,  Pari  1:  General  Procedures.  April  1993  (X. 660: 1992) 

ISOAEC  9834-1  PD  AM  1  Amendment  1:  Object  Identifier  Component  Attribute  Type  in  Annex  B  to  Accommodate 

'Short  Form  Names* 
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ISO/IEC  9834-1  WDAM  2  Amendment  2:  Incorporation  of  Definition  of  Root  Area  of  Object  Identifier  Tree  (PD AM 
December  1994,  DAM  December  1993,  and  AM  December  1996) 

ISO/IEC  9834-2*  Information  Technology  -  Open  Syitems  Interconnection  -  Procedure*  for  the  Operation  of  OSI 
Regulation  Authorities  Part  2:  Registration  Procedure*  for  OSI  Document  Types,  July  1993 
(SC21  N  8149} 

ISO/IEC  9834-3*  Information  Technology  -  Open  Systems  Interconnection  -  Procedures  for  the  Operation  of  OSI 
Registration  Authorities,  Part  3:  Registration  of  Object  Identifier  Component  Values  for  Joint  ISO- 
ccrrr  Use,  September  1990  [SC21  N  4718,  April  1990]  (X.662) 

ISO/IEC  9834-3  WDAM  1  Amendment  1:  Alignment  with  ISO/IEC  9834-1:1993  (PDAM  December  1994,  DAM  December 
1993,  and  AM  December  1996) 


ISO/IEC  9834-4* 
ISO/IEC  9834-3* 
ISO/IEC  9834-6* 

WD  9834-7 

WD  9834-8 

WD  9834-11 

WD9834-B 

WD9834-C 

ISO  9899 
ISO  9945-1 

CD  9945-1.1 

CD  9945-1.2 

CD  9945-1.3 

CD  9945-1.3.1 

CD  9945-1.3.2 

CD  9945-1.3.3 

CD  9945-13.4 

DIS  9945-2.1 

CD  9945-2.2 

CD  9945-3 

CD  9945-3.1 

CD  9945-3.2 

DP  9955 

ISO/IEC  1R  9973 
ISO  9979 

MS  9995-1 


Information  Technology  -  Open  Systems  Interconnection  -  Procedures  for  the  Operation  of  OSI 
Registration  Authorities,  Part  4:  Register  of  VTE  Profiles,  November  1991 
Information  Technology  -  Open  Systems  Interconnection  -  Procedures  for  the  Operation  of  OSI 
Registration  Authorities,  Psrt  5:  Register  of  VT  Control  Objects  Definitions,  November  1991 
Information  Technology  -  Open  Systems  Interconnection  -  Procedures  for  the  Operation  of  OSI 
Registration  Authorities,  Part  6:  Registration  of  Procedures  for  Application  Processes  and 
Application  Entities,  November  1993  (X.663:1992) 

Information  Technology  -  Open  Systems  Interconnection  -  Procedures  for  the  Operation  of  OSI 
Registration  Authorities,  Part  D:  Registration  of  Application  Contexts,  1990  (work  suspended  by 
SC21,  November  1989)  (SC21  has  asked  JTC1  for  endorsement  to  cancel  the  project) 

Information  Technology  -  Open  Systems  Interconnection  -  Procedures  for  the  Operation  of  OSI 
Registration  Authorities,  Part  E:  Registration  of  System  Titles,  1990  (will  probably  be 
incorporated  in  OSI  management  standards)  (SC21  has  asked  JTC1  for  endorsement  to  cancel  the 
project) 

Information  Technology  -  Open  Systems  Interconnection  -  Procedures  for  the  Operation  of  OSI 
Registration  Authorities,  Part  F:  Registration  of  Authentication  Mechanisms,  1990 
(WITHDRAWN;  canceled  by  SC21,  November  1989) 

Information  Technology  •  Open  Systems  Interconnection  -  Procedures  for  the  Operation  of  OSI 
Registration  Authorities,  Part  B:  Registration  of  Abstract  Syntaxes,  1990 

Information  Technology  -  Open  Systems  Interconnection  -  Procedures  for  the  Operation  of  OSI 
Registration  Authorities,  Part  C:  Registration  of  Transfer  Syntaxes,  1990 
Information  Technology  -  Programming  Languages  -  C.  1990  (ANSI/ISO  9899-1990) 

Information  Technology  -  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  l:  System  Application  Program  Interface  (API),  1990 

Information  Technology  •  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  1.1:  Language  Independent  Base  (WG15  work  item  based  on  IEEE  P1003.1c) 
Information  Technology  •  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  1.2:  Real-time  and  Extensions  (WG15  work  item  based  on  IEEE  P1003.4  and  .lb) 
Information  Technology  >  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  13:  Distribution  Services  (WG15  work  item  based  on  IEEE  P1003.8) 

Information  Technology  -  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  13.1:  Transparent  File  Access  (WG15  work  item  based  on  IEEE  P1003.8) 
Information  Technology  -  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  133:  Remote  Procedure  Call  (WG15  work  item  based  on  IEEE  P1237) 

Information  Technology  •  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  13.3:  Transport  Interface  (WG15  work  item  based  on  IEEE  P10Q3.il) 

Information  Technology  •  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  1 3.4:  Name  Space/Directory  Services  (WG15  work  hem  based  on  IEEE  P10Q3.12) 
Information  Technology  •  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  2.1:  Shell  and  Utilities  (WG13  work  item  based  on  IEEE  P1003.2) 

Information  Technology  •  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  2.2:  User  Portability  Extensions  (WG15  work  item  based  on  IEEE  P10Q3.2a) 
Information  Technology  •  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  1:  System  Management 

Information  Technology  -  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Part  3.1:  General  Services  (WG15  work  item  based  on  IEEE  P1003.7) 

Information  Technology  •  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX),  Psrt  3.2:  Batch  Services  (WG13  work  item  based  on  IEEE  PI 003. 10) 

Methodology  and  Guidelines  for  the  Development  of  Application  Protocols  for  Banking 

Information  Interchange  [SC21  N  7706],  30  March  1993 

Information  Processing  -  Procedures  for  Registration  of  Graphical  Items,  1988 

Information  Processing  •  Data  Encipherment  -  Procedures  for  the  Registration  of  Cryptographic 

Algorithms,  1991  (SC27  N  88] 

Information  Technology,  Keyboard  Layouts  for  Text  and  Office  Systems,  Part  1:  General 
Principles  Governing  Keyboard  Layouts,  4  November  1991 
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DIS  9993-2  Information  Technology,  Keyboard  Layout*  for  Taut  and  Office  Syatesu,  Part  2:  Alphanmnaric 

Section,  4  November  1991 

DIS  9995-3  Information  Technology,  Keyboard  Layout*  for  Text  and  Office  Systems,  Part  3:  Common 

Secondary  Layout  of  Alphanumeric  Zone  of  Alphanumeric  Section,  4  November  1991 
IMS  9995-4  Information  Technology,  Keyboard  Layout*  for  Text  and  Office  Systems,  Part  4:  Principles 

Governing  the  Placement  of  Characters  and  Symbols  on  Keys.  4  November  1991 
DIS  9993-3  Information  Technology,  Keyboard  Layouts  for  Text  and  Office  Systems,  Part  5:  Editing  Section, 

November  1991 

US  9995-6  Information  Technology,  Keyboard  Layout*  for  Text  and  Office  Systems,  Part  6:  Functional 

Section,  4  November  1991 

IXS  9995-7  Information  Technology,  Keyboard  Layout*  for  Text  and  Office  Systems,  Part  7:  Symbols  Used  to 

Represent  Functions,  4  November  1991 

IXS  9995-8  Information  Technology,  Keyboard  Layouts  for  Text  and  Office  Systems,  Part  8:  Allocation  of 

Letters  to  the  Keys  of  a  Numeric  Keyboard 

ISQ/IBC  TR  10000-1*  Information  Technology  -  Framework  and  Taxonomy  of  International  Standardized  Profiles  (ISPs), 
Part  1:  Framework,  Edition  2, 1992 

WDTR  10000-1.3  Information  Technology  -  Framework  and  Taxonomy  of  International  Standardized  Profiles  (ISPs), 
Part  1:  Taxonomy,  Edition  3,  July  1993 

ISQ/IEC  TR  10000-2*  Information  Technology  -  Framework  and  Taxonomy  of  International  Standardized  Profiles,  Pan  2: 

Taxonomy  of  OSI  Profile,  Edition  2.  November  1991  [SGFS  N  430] 

DTK  10000-23  Information  Technology  -  Framework  and  Taxonomy  of  International  Standardized  Profiles,  Part  2: 
Taxonomy  of  Profiles,  Edition  3,  August  1992 

WDTR  10000-3  Information  Technology  -  Framework  and  Taxonomy  of  International  Standardized  Profiles,  Part  3: 
Principle*  and  Taxonomy  for  OSE  Profiles,  August  1993 

ISQ/IEC  10021-1*  Information  Processing  -  Text  Communication  -  Message  Oriented  Text  Interchange  System 
(MOTIS),  Part  1:  System  and  Service  Overview,  1990  (see  X.400) 

ISQ/IEC  10021-1/Cor  1  Technical  Corrigendum  1.  1991 
ISO/IEC  10021-1/Cor  2  Technical  Corrigendum  2,  1991 
ISQ/IEC  10021-1/Cor  3  Technical  Corrigendum  3,  1992 
ISO/IEC  10021-1/Cor  4  Technical  Corrigendum  4,  1992 
ISQ/IEC  10021-1/Cor  5  Technical  Corrigendum  3.  1992 

ISQ/IEC  10021-2*  Information  Technology  -  Text  Communication  -  Message  Oriented  Text  Interchange  System 
(MOTIS),  Part  2:  Overall  Architecture,  1990  (see  X.402) 

ISO/IEC  10021-2/Cor  1  Technical  Corrigendum  1.  1991 
ISQ/IEC  10021-2/Cor  2  Technical  Corrigendum  2.  1991 
ISO/IEC  10021-2/Cor  3  Technical  Corrigendum  3.  1992 
ISO/IEC  10021-2/Cor  4  Technical  Corrigendum  4.  1992 

ISQ/IEC  10021-2  PD  AM  1  Amendment  1:  Representation  of  Q/R  Addresses  for  Human  Exchange,  June  1991 
ISQ/IEC  10021-2  PDAM  2  Amendment  2:  Minor  Enhancements,  June  1991 

ISQ/IEC  10021-3*  Information  Technology  •  Text  Communication  -  Message  Oriented  Text  Interchange  System 
(MOTIS),  Part  3:  Abstract  Service  Definition  Conventions,  1990  (see  X.407) 

ISO/IEC  10021-3/Cor  1  Technical  Corrigendum  1, 1992 

ISQ/IEC  10021-4*  Information  Technology  -  Text  Communication  -  Message  Oriented  Text  Interchange  System 
(MOTIS),  Part  4:  Message  Transfer  System:  Abstract  Service  Definition  and  Procedures,  1990  (see 
X.4U) 

ISO/IEC  10021-4/Cor  1  Technical  Corrigendum  1,  1991 
ISO/IEC  10021-4/Cor  2  Technical  Corrigendum  2,  1991 
ISO/IEC  10021-4/Cor  3  Technical  Corrigendum  3,  1992 
ISO/IEC  10021-4/Cor  4  Technical  Corrigendum  4,  1992 
ISO/IEC  10021-4/Cor  5  Technical  Corrigendum  3.  1992 
ISQ/IEC  10021-4  PDAM  1  Amendment  l:  Minor  Enhancement*.  June  1991 

ISO/IEC  10021-3*  Information  Technology  •  Text  Communication  -  Message  Oriented  Text  Interchange  System 
(MOTIS),  Part  5:  Message  Store:  Abstract  Service  Definition,  1990  (see  X.413) 

ISO/IEC  10021-3/Cor  1  Technical  Corrigendum  1. 1991 
ISQ/IEC  10021-5/Cor  2  Technical  Corrigendum  2, 1991 
ISO/IEC  10021-5/Cor  3  Technical  Corrigendum  3,  1992 
ISO/IBC  10021-3/Cor  4  Technical  Corrigendum  4, 1992 
ISQ/IEC  10021-5/Cor  S  Technical  Corrigendum  5,  1992 

ISQ/IEC  10021-6*  Information  Technology  •  Text  Communication  -  Message  Oriented  Text  Interchange  System 
(MOTIS),  Part  6:  Protocol  Specifications,  1990  (see  X.419) 

ISO/IEC  10021-6/Cor  1  Technical  Corrigendum  1,  1991 
ISO/IEC  10021-6/Cor  2  Technical  Corrigendum  2, 1991 
ISO/IEC  10021-6/Cor  3  Technical  Corrigendum  3,  1992 
ISO/IEC  10021-6/Cor  4  Technical  Corrigendum  4. 1992 
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ISO/IEC  10021-6/Cor  S  Technical  Corrigendum  3,  1992 

ISO/IEC  10021-7*  Information  Technology  -  Text  Communication  -  Menage  Oriented  Text  Interchange  Syctem 
(MOTIS),  Part  7:  Interpersonal  Meetaging  System,  1990  (tee  X.420) 

ISO/IEC  10021-7/Cor  1  Technical  Cofrigendum  1,  1991 
Technical  Corrigendum  2,  1991 
Technical  Corrigendum  3.  1992 
Technical  Corrigendum  4,  1992 
Technical  Corrigendum  3,  1992 


ISO/IEC  10021-7/Cor  2 
ISO/IEC  ! 0021-7/Cor  3 
ISO/IEC  10021-7/Cor  4 
ISO/IEC  10021-7/Cor  3 


ISO/IEC  10021-7  PD  AM  1  Amendment  1:  Minor  Enhancements,  June  1991 
ISO/IEC  10021-11 


ISO/IEC  10021-12 


ISO/IEC  10021-13 


ISO/IEC  10021-14 


ISO/IEC  10021-13 


ISO/IEC  10022* 


ISO/IEC  TR  10023* 


ISO/IEC  TR  10024* 


ISO/IEC  10023-1* 


ISO/IEC  10023-2* 


ISO/IEC  10023-3* 


ISO/IEC  10026-1* 


Message  Oriented  Text  Interchange  System 
Message  Oriented  Text  Interchange  System 


Information  Technology  -  Text  Communication  • 

(MOHS),  Part  11:  MTS  Routing,  February  1991 
Information  Technology  -  Text  Communication 
(MOTIS),  Part  12:  PICS  Proforma  for  Message  Transfer  Protocol,  June  1991 
Information  Technology  -  Text  Communication  •  Message  Oriented  Text  Interchange  System 
(MOTIS),  Part  13:  PICS  Proforma  for  Message  Transfer  Access  Protocol,  June  1991 
Information  Technology  -  Text  Communication  -  Message  Oriented  Text  Interchange  System 
(MOTIS),  Part  14:  PICS  Proforma  for  Message  Store  Access  Protocol,  June  1991 
Information  Technology  -  Text  Communication  •  Message  Oriented  Text  Interchange  System 
(MOHS),  Part  13:  PICS  Proforma  for  Interpersonal  Messaging,  July  1991 

Information  Technology  -  Open  Systems  Interconnection  -  Physical  Service  Definition  (X.211), 
August  1990 

Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Formal  Description  of  ISO/IEC  8072  in  LOTOS,  1992 

Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Formal  Description  of  ISO/IEC  8073  (Classes  0,  1,  2,  3)  in  LOTOS,  1992 

Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Transport  Conformance  Testing  for  Connection  Oriented  Transport  Protocol  Operating  over  the 
Connection  Oriented  Network  Service  (CONS),  Part  1:  General  Principles,  1993 
Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Transport  Conformance  Testing  for  Connection  Oriented  Transport  Protocol  Operating  over  the 
Connection  Oriented  Network  Service  (CONS),  Part  2:  Test  Suite  Structure  and  Test  Principles, 
1993 

Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  • 
Transport  Conformance  Testing  for  Connection  Oriented  Transport  Protocol  Operating  over  the 
Connection  Oriented  Network  Service  (CONS),  Part  3:  Transport  Test  Management  Protocol 
Specification,  1993 

Information  Technology  -  Open  Systems  Interconnection  -  Distributed  Transaction  Processing 
(TP),  Part  1:  Model,  December  1992  [SC21  N  7457]  (X.860:1992) 

ISO/IEC  10026-1  PD  AM  1  Amendment  1:  Commitment  Optimization,  September  1993  [SC21  N  8219,  8220,  7649) 
(DAM  expected  June  1994;  and  AM  expected  June  1993) 

ISO/IEC  10026-1/3  WDAMs  Draft  Amendments  to  Parts  1-3:  Distributed  Transaction  Processing  Dialogue  Recovery  and 
User  Suspension  of  a  Dialogue  [SC21  N  6710]  (PD AMs  expected  November  1995,  DAMs 
November  1996,  and  AMs  November  1997) 

ISO/IEC  10026-1/3  WDAMs  Draft  Amendments  to  Parts  1-3:  Transaction  Processing  Association  Pool  Management, 
WDAMs,  February  1992  [SC21  N  7604]  (formerly  entitled  Association  Management)  (PDAMs 
expected  July  1994,  DAM  July  1993,  and  AM  July  1996) 

ISO/IEC  10026-1/3  WDAMs  Draft  Amendments  to  Parts  1-3:  Transaction  Processing  Sub-Transactions.  SC21/WGS, 
WDAMs,  July  1991  [SC21  N  6236]  (PDAMs  expected  November  1995,  DAMs  November  1996.  and 
AMs  November  1997) 

ISO/IEC  10026-1/4  WDAMs  Draft  Amendments  to  Parts  1-3:  Transaction  Processing  Separate  Data  and  Commit 
Associations,  WDAMs,  July  1991  (SC 21  N  6240]  (PDAMs  expected  November  1995,  DAMs 
November  1996,  and  AMs  Novmber  1997) 

ISO/IEC  10026-1/3  WDAMs  Draft  Amendments  to  Parts  1-3:  Transaction  Processing  Security,  WDAMs,  July  1991 
(SC21  N  6232]  (PDAMs  expected  November  1995;  DAMs  November  1996;  and  AMs 
November  1997) 

ISO/IEC  10026-2*  Information  Technology  •  Open  Systems  Interconnection  -  Distributed  Transaction  Processing 
(TP),  Part  2:  Service,  August  1992  [SC21  N  7304]  (X.861.1992) 

ISO/IEC  10026-2  PDAM  1  Amendment  1:  Commitment  Optimizations,  September  1993  [SC21  N  8220) 

ISO/IEC  10026-3*  Information  Technology  -  Open  Systems  Interconnection  -  Distributed  Transaction  Processing 
(TP),  Part  3:  Transaction  Processing  Protocol  Specification,  December  1992  [SC21  N  7318] 
(X.862) 

ISO/IEC  10026-3  PDAM  1  Amendment  1:  Commitment  Optimizations,  September  1993  [SC21  N  7649] 

ISO/IEC  10026-4  Information  Technology  -  Open  Systems  Interconnection  -  Distributed  Transaction  Processing 
(TP),  Part  4:  PICS  Proforma,  SC21/WG5.  October  1993  [SC21  N  8290]  (X.863) 

ISO/IEC  10026-5  Information  Technology  -  Open  Systems  Interconnection  -  Distributed  Transaction  Processing 
(TP),  Part  3:  Application  Context  Proforma,  1993 
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1SO/IEC  10026-6  Information  Technology  -  Open  Systems  Interconnection  -  Distributed  Transaction  Processing 
(TP),  Part  6:  Unstructured  Data  Transfer,  1993 

CD  10026-7  Information  Technology  -  Open  Systems  Interconnection  -  Distributed  Transaction  Processing 

(TP),  Part  7:  Message  Queueing,  July  1993  [SC21  N  8148) 

ISO/IEC  10027  Information  Technology  -  Information  Resource  Dictionary  System  (IRDS)  Framework.  June  1990 

WD  10027.2  Information  Technology  -  Information  Resource  Dictionary  System  (IRDS)  Framework,  Edition  2 

(revision  to  address  new  requirements  and  alignment  with  RMDM,  SQL,  RDA,  Directory,  and  ODP), 
1993  [SC21  N  8204]  (CD  expected  July  1994) 

ISO/IEC  10028-1*  Definition  of  the  Relaying  Functions  of  a  Network  Layer  Intermediate  System,  Part  1:  Connection¬ 
mode  Network  Service,  1993 

ISO/IEC  10028-1  PDAM  1  Amendment  1:  Connectionless  Mode  Relaying  Functions,  February  1991 
ISCVIEC  10028-2*  Definition  of  the  Relaying  Functions  of  a  Network  Layer  Intermediate  System,  Part  2: 
Connectionless  Network  Service,  1993 

ISO/IEC  TR  10029*  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Operation  of  an  X.25  Interworking  Unit,  March  1989 

ISO/IEC  10030  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  -  End 

System  to  Intermediate  System  Routing  Information  Exchange  Protocol  for  Use  in  Conjunction 
with  ISO/IEC  8878  (X.25  PLP)  [SC6  N  5006],  October  1990 
ISO/IEC  10030/Cor  1  Technical  Corrigendum  1,  1992 

ISO/IEC  10030  PDAM  1  Amendment  1:  Dynamic  Discovery  of  OSI NASP  Addresses  by  End  Systems  (New  Work  Item) 
ISO/IEC  10030  AM  2  PICS  Proforma,  1992  (see  DIS  10030-2) 

ISO/IEC  10030  PDAM  3  Amendment  3:  Specification  of  IS-SNARE  Interactions,  August  1991 

DIS  10030-2  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  -  End 

System  to  Intermediate  System  Routing  Information  Exchange  Protocol  for  Use  in  Conjunction 
with  ISO/IEC  8878  (X.25  PLP),  Part  2:  PICS  Proforma,  October  1991 
ISO/IEC  10031-1  Information  Processing  -  Text  and  Office  Systems  -  Distributed-Office-Applications  Model 
(DOAM),  Part  1:  General  Model,  1991 

ISO/IEC  10031-2  Information  Processing  -  Text  and  Office  Systems  -  Distributed-Office-Applications  Model 
(DOAM),  Part  2:  Distinguished  Object  References  and  Associated  Procedures,  1991 
ISO/IEC  10032  Information  Technology  -  Reference  Model  of  Data  Management,  January  1992 

DP  10033  Information  Processing  -  Text  and  Office  Systems  -  Recording  of  Documents  Conforming  to 

ISO/IEC  8613  on  Flexible  Disk  Cartridges  Conforming  to  ISO/IEC  9293,  May  1988 
ISO/IEC  TR  10034  Guidelines  for  the  Preparation  of  Conformity  Clauses  in  Programming  Language  Standards.  1990 
ISO/IEC  10035*  Information  Technology  •  Open  Systems  Interconnection  -  Connectionless  ACSE  Protocol 
Specification.  July  .291  (X.237:1992) 

ISO/IEC  10035  WDAM  1  Amendment  1:  Extensions  to  Support  the  Extended  Application  Layer  Structure.  December 
1993  [SC21/WG8  N  196] 

DIS  10035-2  Information  Technology  -  Open  Systems  Interconnection  -  Connectionless  ACSE  Protocol 

Specification,  Part  2:  PICS  Proforma  for  Connectionless  ACSE  Protocol,  November  1993 
[SC21  N  7870  rev]  (initiation  of  ITU-TS  approval  ballot  expected  November  1994)  (X.257) 
ISO/IEC  10036  Information  Technology  -  Font  Information  Exchange  -  Procedure  for  Registration  of  Glyph  and 
Glyph  Collection  Identifiers,  1993 

ISO/IEC  TR  10037  Information  Technology  -  SGML  and  Text-Entry  Systems  -  Guidelines  for  SGML  Syntax-Directed 
Editing  Systems,  1991 

DIS  10038*  Information  Technology  -  Local  Area  Networks  -  MAC  Sublayer  Interconnection  (MAC  Bridging) 

(awaiting  DIS  ballot),  December  1991 

US  10038  PDAM  1  Amendment  1:  Specification  of  Management  Information  for  CMIP  (awaiting  PDAM  ballot) 

US  10038  DAM  2  Amendment  2:  Source  Routing  Supplement,  October  1991 

ISO/IEC  10039*  Information  Technology  -  Open  Systems  Interconnection  -  Local  Area  Networks  -  MAC  Service 

Definition,  October  1990 

ISO/IEC  10040*  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management  Overview, 
Edition  2,  1992  (X.701:1992) 

ISO/IEC  10040/Cor  1  Technical  Corrigendum  1.  October  1993  [SC21  N  8291] 

ISO/IEC  10040  AM  1  Amendment  1:  Management  Knowledge  Management  Architecture.  January  1993  [SC21  N  7527] 
(passed  DIS  ballot  October  1993;  IS  text  awaits  resolution  of  ballot  comments) 

ISO/IEC  10040  PDAM  2  Amendment  2:  Management  Domains  Architecture,  June  1993  [SC21  N  7946]  (editing  meeting 
April  1994) 

ISO/IEC  10116  Information  Technology  -  Modes  of  Operation  for  an  N-bit  Block  Cipher  Algorithm,  1991 

DIS  10118-1  Information  Technology  -  Security  Techniques  -  Hash  Functions,  Part  1:  General  Model, 

SC27/WG2,  1993 

DIS  10118-2  Information  Technology  -  Security  Techniques  •  Hash  Functions,  Part  2:  Hashing  Operation  Using 

Symmetric  Block-Cipher  Algorithm,  SC27/WG2,  1993 

WD  10118-3  Information  Technology  •  Security  Techniques  -  Hash  Functions,  Part  3:  Dedicated  Hash  Functions, 

SC27/WG2,  SC27  N  223,  1993 
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WD  10118-4  Infonnatioa  Technology  -  Security  Techniques  -  Hah  Functions,  Put  4:  Hah  Functions  Using 

Modular  Arithmetic,  SC27/WG2  N  21. 1993 

ISO/IEC  10126-1  Financial  Transactions  -  Wholesale  Banking  Security  -  Procedures  for  Message  Encipherment,  Part 
1:  General  Principles,  TC  68/SC 2,  1993 

1SO/IEC  10126-2  Financial  Transactions  -  Wholesale  Banking  Security  -  Procedures  for  Message  Encipherment,  Part 
2.  DEA-  Algorithms,  TC68/SC2.  1993 

WD  10148.3  Information  Technology  -  Basic  Remote  Procedure  Call  (RPC)  Using  OSI  Remote  Operations  (fast- 

track  ballot  failed  and  DIS  10148  wu  withdrawn  (revised  effort  in  DIS  11578,  September  1993) 

ISO  10149  Information  Processing  Systems  -  Data  Interchange  on  Read-Only  120-mm  Optical  Data  Disks  (CD- 

ROM).  August  1988 

DIS  10161-2  Information  and  Documentation  -  Open  Systems  Interconnection  -  Interlibrary  Loan  Application 

Protocol  Specification,  Part  2:  Protocol  Implementation  Conformance  Statement  Proforma, 
March  1993  [SC21  N  7657] 

ISO/IEC  10162  Information  and  Documentation  •  Search  and  Retrieve  Application  Service  Definition  for  Open 
Systems  Interconnection,  1993 

ISO/IEC  10163  Information  and  Documentation  -  Search  and  Retrieve  Application  Protocol  Specification  for  Open 
Systems  Interconnection,  1993 

ISO/IEC  10164-1*  Information  Technology  -  Open  Systems  Interconnection  •  Systems  Management,  Part  1:  Object 
Management  Function,  June  1993  (X. 730;  1992) 

ISO/IEC  10164-1  DAM  1  Amendment  1:  ICS  Proforma  (previoucly  MOCS/PICS  Proforma),  September  1993 
[SC21  N  8240]  (editing  meeting  July  1994;  initiation  of  ITU-TS  approval  ballot  expected 
November  1994) 

ISO/IEC  10164-2*  Infonnatioa  Technology  -  Open  Systems  Interconnection  -  Systems  Management,  Part  2:  State 
Management  Function,  June  1993  (X.731:1992) 

ISO/IEC  10164-2  DAM  1  Amendment  1:  ICS  Proforma,  September  1993  [SC21  N  8241]  (editing  meeting  July  1994; 

initiation  of  ITU-TS  approval  ballot  expected  November  1994) 

ISCVIEC  10164-3*  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management,  Part  3: 

Attributes  for  Representing  Relationship,  June  1993  (X.732:1992) 

ISO/IEC  10164-3  DAM  1  Amendment  1:  ICS  Proforma,  September  1993  [SC21  N  8242]  (editing  meeting  July  1994; 

initiation  of  ITU-TS  approval  ballot  expected  November  1994) 

ISO/IEC  10164-4*  Information  Technology  •  Open  Systems  Interconnection  -  Systems  Management,  Part  4:  Alarm 
Reporting  Function,  December  1992  (X. 733:1992) 

ISO/IEC  10164-4  DAM  1  Amendment  1:  ICS  Proforma.  September  1993  ISC21  N  8243]  (editing  meeting  July  1994; 

initiation  of  ITU-TS  approval  ballot  expected  November  1994) 

ISO/IEC  10164-5*  Information  Technology  •  Open  Systems  Interconnection  -  Systems  Management,  Part  5:  Event 
Report  Management  Function,  Jane  1993  (name  changed  from  Management  Service  Control 
Function)  (X.734:1992) 

ISO/IEC  10164-5  DAM  1  Amendment  1:  ICS  Proforma,  September  1993  [SC21  N  8244]  (editing  meeting  July  1994; 

initiation  of  ITU-TS  approval  ballot  expected  November  1994) 

ISO/IEC  10164-5  PDAM  2  Amendment  2:  Enhanced  Discriminator.  August  1993  (editing  meeting  April  1994) 

ISO/IEC  10164-6*  Information  Technology  •  Open  Systems  Interconnection  -  Systems  Management.  Part  6:  Log 
Control  Function,  November  1993  (X. 735:1992) 

ISO/IEC  10164-6  DAM  1  Amendment  1:  ICS  Proforma,  September  1993  [SC21  N  8245]  (editing  meeting  July  1994; 

initiation  of  ITU-TS  ^firoval  ballot  expected  November  1994) 

ISO/IEC  10164-6  PDAM  2  Amendment  2:  Enhanced  Log,  August  1993  (editing  meeting  April  1994) 

ISO/IEC  10164-7*.  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management.  Part  7:  Security 
Alarm  Reporting  Function,  May  1992  (X.736:1992) 

ISO/IEC  10164-7  DAM  1  Amendment  1:  ICS  Proforma,  September  1993  (SC21  N  8246]  (editing  meeting  Inly  1994; 

initiation  of  ITU-TS  approval  ballot  expected  November  1994) 

ISO/IEC  10164-8*  Information  Technology  -  Open  Systems  Intercoonection  -  Systems  Management,  Part  8:  Security 
Audit  Trail  Function.  June  1993  (X.740:I992) 

ISO/IEC  10164-8/Cor  1  Draft  Technical  Corrigendum  1,  January  1994  [SC21  N  8427] 

ISO/IEC  10164-9*  Information  Technology  -  Open  System*  Interconnection  -  Systems  Management,  Part  9:  Object* 
and  Attribute*  for  Access  Control,  November  1993  [SC21  N  7661]  (editing  meeting  February  1994; 
initiation  of  ITU-TS  approval  ballot  expected  November  1994)  (X.741) 

IHS  10164-10.2  Information  Technology  •  Open  Systems  Interconnection  •  System*  Management,  Part  10.  Uaage 
Metering  Function  (formerly  Accounting  Meter  Function),  November  1993  [SC21  N  8238]  (ballot 
closes  February  1994;  editing  meeting  July  1994;  initiation  of  ITU-TS  approval  ballot  expected 
November  1994)  (X.742) 

ISO/IEC  10164-10  WDAM  1  Amendment  1:  ICS  Proforma,  1993  (PDAM  expected  July  1994) 

ISO/IEC  10164-11*  Information  Technology  •  Open  Systems  Interconnection  -  Systems  Management,  Pot  11:  Metric 
Objects  and  Attributes  (formerly  Workload  Monitoring  Function),  Match  1993  [SC21  N  7533] 
(X.739:1993) 

ISO/IEC  10164-11  WDAM  1  Amendment  1:  ICS  Proforma,  September  1993  (SC21  N  8162]  (PDAM  expected  July  1994) 
ISO/IEC  10164-11  WDAM  2  Amendment  2:  Additional  Metric  Objects  and  Attributes,  September  1993  [SC21  N  8161] 
(PDAM  expected  July  1994) 
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ISOAEC  10164-12*  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management,  Part  12:  Test 
Management  Function  December  1992  [SC21  N  7432}  (X.745:1993) 

ISOAEC  10164-12  PDAM  1  Ametxhneot  I:  ICS  Proforma.  November  1993  [SC21  N  8333] 

ISOAEC  10164-13*  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management,  Part  13: 

Summarization  Function  (formerly  Measurement  Summarization  Function),  September  1993 
(SC21  N  8160]  (X.738:1993) 

ISOAEC 10164-13  WDAM 1  Amendment  1:  ICS  Proforma,  September  1993  [SC 21  N  8163]  (PDAM  expected 
December  1993) 

ISOAEC 10164-13  WDAM  2  Amendment  2:  Additional  Summarization  Scanners.  July  1993  [SC21  N  7963]  (PDAM 
expected  December  1993) 

DiS  10164-14.2  Information  Technology  -  Open  Systems  Interconnection  •  Systems  Management,  Part  14: 

Confidence  and  Diagnostic  Test  Categories,  January  1993  [SC21  N  7434]  (editing  meeting  in 
October  1993  proposed  a  second  DIS;  initiation  of  ITU-TS  approval  ballot  expected  February  1994) 
(X.737) 

DIS  10164-13  Information  Technology  •  Open  Systems  Interconnection  -  Systems  Management,  Part  15: 

Scheduling  Function,  May  1993  [SC21  N  7683]  (editing  meeting  February  1994;  initiation  of  ITU- 
TS  approval  ballot  expected  November  1994)  (X.746) 

CD  10164-16.2  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management,  Part  16: 

Management  Knowledge  Management,  October  1993  [SC21  N  8310]  (initiation  of  ITU-TS 
approval  ballot  expected  November  1994)  (X.750) 

CD  10164-17  Information  Technology  •  Open  Systems  Interconnection  -  Systems  Management,  Part  17:  Change 

Over  Function,  January  1994  [SC21  N  8422]  (initiation  of  ITU-TS  approval  ballot  expected  in 
1997)  (X.751) 

CD  10164-19  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management,  Part  19: 

Management  Domain  and  Management  Policy  Management  Function,  January  1994 
[SC21  N  8423]  (initiation  of  ITU-TS  approval  ballot  expected  in  1997)  (X.749) 

WD  10164-ev.2  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management.  Part  ev: 

Enhanced  Event  Control  Function,  July  1992  [SC21  N  7938]  (CD  expected  December  1993; 
initiation  of  ITU-TS  approval  ballot  expected  in  1997)  (X.746) 

WD  10164-mo  Information  Technology  •  Open  Systems  Interconnection  •  Systems  Management,  Part  mo: 

Managed  Objects  for  Supporting  Upper  Layers,  January  1994  [SC21  N  8434] 

WD  10164-nn.2  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management,  Part  mo:  General 
Relationship  Management  Function,  June  1993  [SC21  N  8040]  (CD  text  expected  December  1994, 
US  June  1996,  end  IS  June  1997)  (X. 747) 

WD  10164-rtm  Information  Technology  •  Open  Systems  Interconnection  •  Systems  Management,  Part  rtm: 

Response  Urns  Monitoring  Punction,  August  1990  [SC21  7970]  (CD  expected  December  1993; 
initiation  of  ITU-TS  approval  ballot  expected  in  1998)  (X.748) 

WD  10164-aw  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management,  Part  x:  Software 

Management  Function.  September  1993  [SC21  N  8201]  (CD  expected  December  1993;  initiation  of 
ITU-TS  approval  ballot  expected  in  1997)  (X.744) 

WD  10164-tm.2  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management,  Part  y:  Time 
Management  Function,  July  1993  (SC21  N  7961]  [JTC1  N  763]  (new  work  item;  standard  will  have 
two  parts:  representation  of  time  and  mechanisms  for  the  distribution  and  synchronization  of  time; 
CD  expected  July  1994;  initiation  of  ITU-TS  approval  ballot  expected  in  1998)  (X.743) 

ISCVTEC  10163-1*  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of  Management  Information, 
Part  1:  Management  Information  Model,  September  1993  (X.720: 1992) 

ISOAEC  10165-1/Cor  1  Technical  Corrigendum  1.  December  1993  [SC21  N  8360] 

ISOAEC  10163-1  PDAM  1  Amendment  1:  Generalization  of  Terms  (formerly  General  Relationship  Model),  June  1993 
[SC21  N  7947]  (editing  meeting  February  1994) 

ISOAEC  10163-2*  Information  Technology  •  Open  Systems  Interconnection  •  Structure  of  Management  Information. 

tat  2:  Definition  of  Management  Information,  October  1992  (incorporated  Part  3)  (X.721:1992) 
ISOAEC  10165-2/Cor  1  Draft  Technical  Corrigendum  1,  July  1993  [SC21  N  7933] 

ISOAEC  10163-2  PDAM  12  Amendment  1:  Enhanced  Discriminator  and  Log,  January  1993  [SC21  N  7539]  (WG4 
recommended  in  October  1993  a  second  PDAM  ballot;  editing  meeting  April  1994) 

ISOAEC  10163-4*  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of  Management  Information, 
Part  4:  Guidelines  for  the  Definition  of  Managed  Objects,  September  1992  (X.722:1992) 

ISOAEC  10165-4  PDAM  1  Amendment  1:  GDMO  Extensions,  July  1993  (SC21  N  7948]  (editing  meeting  February  1994) 
ISOAEC  10163-4  PDAM  2  Amendment  2:  Set  By  Create  and  Component  Registration,  1993  (editing  meeting 
February  1994) 

ISOAEC  10163-3*  Information  Technology  -  Open  Systems  Interconnection  •  Structure  of  Management  Information, 
Part  5:  Generic  Management  Information.  Match  1993  [SC21  N  7640]  (previously  entitled  Generic 
Managed  Objects)  (X.723:1993) 

ISOAEC  10165-6*  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of  Management  Information, 
Part  6:  Requirements  rod  Guidelines  for  Management  Information  Conformance  Statement  (MICS) 
Proformas,  June  1993  (SC21  N  7894]  (X  . 724: 1993) 
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ISQAEC  10165-6  WDAM  !  Amendment  1:  Manager  Role  Confonnance,  July  1993  [SC21  N  7964)  (PDAM  expected 
December  1994) 

ISO/IEC  10165-6/Cor  1  Draft  Technical  Corrigendum  1,  January  1994  [SC21  N  8428) 

CD  10165-7.2*  Information  Technology  •  Open  Systems  Interconnection  -  Structure  of  Management  Information, 
Part  7:  General  Relationship  Model  (formerly  Management  Information  Register  and  Registration 
Procedures),  September  1993  [SC21  N  8036)  (in  the  absence  of  an  editor  and  target  dates,  the  old 
project.  Management  Information  Register  and  Registration  Procedures  has  been  cancelled  [Ref. 
SC 21  N  7728  1993);  editing  meeting  February  1994;  initiation  of  ITU-TS  approval  ballot  expected 
June  1995)  (X.725) 

WD  10165-x  Information  Technology  -  Open  Systems  Interconnection  -  Management  Information  in  the  Upper 

Layers,  October  1993  [SC21  N  8178)  (CD  expected  July  1994) 

ISO/IEC  10166-1  Information  Technology  -  Text  and  Office  Systems  -  Document  Filing  and  Retrieval  (DPR),  Part  1: 
Abstract  Service  Definition  and  Procedures,  June  1991 

ISO/IEC  10166-2  Infonnatioo  Technology  •  Text  and  Office  Systems  -  Document  Filing  and  Retrieval  (DFR),  Part  2: 
Protocol  Specification,  June  1991 

ISO/IEC  TR  10167*  Information  Technology  -  Open  Systems  Interconnection  •  Guidelines  for  the  Application  of 
Estelle,  LOTOS  md  SDL,  November  1991  (Z.1 10) 

IMS  10168-1*  Information  Technology  •  Open  Systems  Interconnection  •  Confonnance  Test  Suite  for  the  Session 

Protocol,  Part  1:  Test  Suite  Structure  and  Test  Purposes,  January  1991  (IS  expected 
December  1994) 

CD  10168-2*  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Test  Suite  for  the  Session 

Protocol,  Part  2:  Common  Session  Abstract  Test  Suite  (formerly  Generic  Test  Suite), 
September  1993  [SC21  N  8164]  (ballot  ends  January  1994) 

CD  10168-3*  Information  Technology  -  Open  Systems  Interconnection  -  Confonnance  Test  Suite  for  the  Session 

Protocol,  Part  3:  Abstract  Test  Suite  for  the  CS  Method  (formerly  Session  Generic  Test  Suite), 
September  1993  [SC21  N  8164]  (ballot  ends  January  1994) 

IMS  10168-4*  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Test  Suite  for  the  Session 

Protocol,  Part  4:  Session  Test  Management  Protocol  Specification.  March  1991  [SC21  N  5026]  (IS 
expected  December  1994) 

ISO/IEC  10169-1*  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Test  Suite  for  the  ACSE 
Protocol,  Part  1:  Test  Suite  Structure  and  Test  Purposes,  November  1991 
WD  10169-2  Information  Technology  •  Open  Systems  Interconnection  -  Confonnance  Test  Suite  for  the  Session 

Protocol,  Part  2:  Common  ACSE  Abstract  Test  Suite  (WD  expected  June  1994;  CD  October  1994; 
IMS  October  1995;  IS  October  1996) 

ISO/IEC  10170-1*  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Test  Suite  for  the  FT  AM 
Protocol,  Part  1:  Test  Suite  Structure  and  Test  Purposes,  April  1993  [SC21  N  7530] 

WD  10170-2  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Test  Suite  for  the  FT  AM 

Protocol,  Part  2:  FT AM  Abstract  Test  Suite,  June  1989  [SC21  N  3665]  (CD  text  expected  October 
1994,  IMS  in  October  1995,  IS  in  October  1996) 

WD  10170-3  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Test  Suite  for  the  FT  AM 

Protocol,  Part  3:  ACSE  Abstract  Test  Suite  Embedded  Under  FT AM,  1989  (formal  WD  text  expected 
June  1994,  CD  text  in  October  1994,  DIS  in  October  1995,  IS  in  October  1996) 

WD  10170-4  Information  Technology  -  Open  Systems  Interconnection  -  Confonnance  Test  Suite  for  the  FT  AM 

Protocol,  Part  4:  Presentation  Abstract  Test  Suite  Embedded  Under  FT AM,  1989  (formal  WD  text 
expected  June  1994,  CD  text  in  October  1994,  DIS  in  October  1995,  IS  in  October  1996) 

WD  10170-5  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Test  Suite  for  the  FT  AM 

Protocol,  Part  5:  Session  Abstract  Test  Suite  Embedded  Under  FT  AM,  1989  (formal  WD  text 
expected  June  1994,  CD  text  in  October  1994,  DIS  in  October  1995,  IS  in  October  1996) 

ISOAEC  TR  10171  List  of  Standard  Data  Link  Layer  Protocols  that  Utilize  HDLC  Classes  of  Procedures  (awaiting 
publication) 

ISO/IEC  TR  10171  PDAM  1  Amendment  1;  Registration  of  XID  Format  Identifiers  and  Private  Parameter  Set  Identifiers 
(ballot  closed  10  March  1991) 

ISO/IEC  TR  10172*  Information  Technology  •  Telecommunications  and  Information  Exchange  Between  Systems  - 
Network/Transport  Protocol  Interworking  Specification,  February  1991 
ISO/IEC  10173*  Information  Technology  •  Integrated  Services  Digital  Network  (ISDN)  -  Primary  Access  Connector 
at  Reference  Points  S  and  T,  March  1991 

DTR  10174  Infonnatioo  Technology  •  Telecommunications  and  Information  Exchange  Between  Systems  - 

Logical  Link  Control  ftyp*  2  Operation)  Test  Purposes,  1993 

IMS  10175  Information  Technology  -  Text  and  Office  Systems  -  Document  Printing  Application  (DPA), 

SC1S/WG4 

ISO/IEC  TR  10176  Information  Technology  -  Guidelines  for  the  Preparation  of  Programming  Language  Standards, 
1991 

ISO/IEC  10177*  Information  Technology  -  Data  Communications  •  Intermediate-System  Support  of  the  OSI 
Connection-Mode  Network  Service  Using  ISO/IEC  8208  in  Accordance  with  ISOTEC  10028, 1993 
ISO/IEC  TR  10178  Information  Technology  -  Telecommunications  and  Infonnatioo  Exchange  Between  Systems  -  The 
Structure  and  Coding  of  Logical  Control  Link  Addresses  in  Local  Area  Networks,  1992 
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1SCVIEC  10179  Document  Style  Semantic*  and  Specification  Language  (DSSSL),  28  June  1991,  awaiting 
publication 

DiS  10180  Standard  Page  Description  Language  (SPFL),  Mvcfa  1991 

CD  10181-1,2*  Infonnation  Technology  •  Open  Systems  Interconnection  -  Security  frameworks  for  Open  Systems, 
Pari  1:  Overview,  August  1992  [SC21  N  7083]  (DIS  expected  January  1994;  IS  September  1994; 
initiation  of  ITU-TS  approval  ballot  expected  November  1994)  (X.810) 

ISO/IEC  10181-2*  Information  Technology  -  Open  Systems  Interconnection  •  Security  Frameworks  for  Open  Systems. 

Part  2:  Authentication  Framework,  December  1993  [SC21  N  78S3]  (passed  DIS  ballot  in 
October  1993;  initiation  of  ITU-TS  approval  ballot  expected  November  1994)  (X.811) 

ISO/IEC 10181-2  WDAM  1  Amendment  1:  Authentication  Elements,  July  1991  [SC21  N  6172]  (new  work  item  in  WG1) 
US  10181-3*  Information  Technology  -  Open  Systems  Interconnection  -  Security  Frameworks  for  Open  Systems, 

Pari  3:  Access  Control  Framework,  June  1992  [SC21  N  6947]  (IS  expected  June  1994;  initiation  of 
ITU-TS  approval  ballot  expected  November  1991)  (X.812) 

US  10181-4*  Information  Technology  -  Open  Syrians  Interconnection  -  Security  Frameworks  for  Open  Systems, 

Part  4:  Non-Repudiation  Frwnewotk,  December  1993  [SC21  N  8378]  (initiation  of  ITU-TS  approval 
ballot  expected  November  1994)  (X.813) 

US  10181-5*  Information  Technology  -  Open  Systems  Interconnection  -  Security  Frameworks  for  Open  Systems. 

Part  5:  Confidentiality  Framework,  February  1993  [SC21  N  76021  (initiation  of  ITU-TS  approval 
ballot  expected  November  1994)  (X.814) 

DIS  10181-6*  Information  Technology  -  Open  Systems  Interconnection  -  Security  Frameworks  for  Open  Systems, 

Part  6:  Integrity  Framework,  February  1993  [SC21  N  7603]  (initiation  of  ITU-TS  approval  ballot 
expected  November  1994)  (X.813) 

CD  10181-7.2*  Information  Technology  -  Open  Systems  Interconnection  -  Security  Frameworks  for  Open  Systems, 
Part  7:  Security  Audit  Framework,  March  1993  [SC21  N  7683]  (initiation  of  ITU-TS  approval  ballot 
expected  November  1994)  (X.816) 

WD  10181-8  Information  Technology  -  Open  Systems  Interconnection  -  Security  Frameworks  for  Open  Systems, 

Part  8:  Key  Management 

DTK  10182  Binding  Techniques  for  Programming  Languages  [SC22/WGU  N  734],  February  1992 

ISOrfEC  TR  10183  Text  and  Office  Systems  -  ODA  and  Interchange  Format  -  Technical  Report  on  ISO/IEC  8613 

Implementation  Testing,  1993 

CD  10184-1.2  Terminal  Management  -  Modal,  July  1991  (SC21  N  4176,  June  1990]  (project  cancelled) 

WD  10184-2  Terminal  Management  -  Service,  July  1991  (SC21  N  4176,  June  1990]  (project  cancelled) 

WD  10184-3  Terminal  Management  -  Protocol,  July  1991  [SC21  N  4176,  June  1990]  (project  cancelled) 

ISO/IEC  10202-1  Financial  Transactions  -  Security  Architecture  •  Security  Architecture  of  Integrated  Circuit  Cards 

(ICCs),  Part  1:  Card  Life  Cycle  TC68/5C6/WG7, 1993 

DIS  10202-2  Financial  Transactions  -  Security  Architecture  -  Security  Architecture  of  Integrated  Circuit  Cards 

(ICCs),  Part  1:  Transaction  Process.  TC68/SC6/WG7,  1993 

CD  10202-3  Financial  Transactions  -  Security  Architecture  -  Security  Architecture  of  Integrated  Circuit  Cards 

(ICCs).  Pvt  1:  Cryptographic  Key  Relationship,  TC68/SC6/WG7,  1993 
ISOAEC  10202-4  Financial  Transactions  -  Security  Architecture  -  Security  Architecture  of  Integrated  Circuit  Cards 
(ICCs),  Part  1;  Secure  Application  Modules.  TC68/SC6/WG7,  1993 
CD  10202-3  Financial  Transactions  -  Security  Architecture  -  Security  Architecture  of  Integrated  Circuit  Cards 

(ICCs),  Part  1:  Use  of  Algorithms.  TC68/5C6/WG7, 1993 

US  10202-6  Financial  Transactions  -  Security  Architecture  -  Security  Architecture  of  Integrated  Circuit  Cards 

(ICCs),  Part  1;  Cardholder  Verification,  TC68/SC6/WG7,  1993 
WD  10202-7  Financial  Transactions  -  Security  Architecture  -  Security  Architecture  of  Integrated  Circuit  Cards 

(ICCs),  Part  1:  Key  Management,  TC68/SC6/WG7,  1993 
ISO/IEC  10206  Information  Technology  -  Programming  Languages  -  Extended  Pascal,  1991 

DIS  10222  Enhanced  Small  Device  Interface,  1991 

ISO/IEC  10279  Informalioo  Technology  -  Programming  Languages  -  Full  BASIC,  1991 

CD  10309-11  Information  Technology  -  Standard  for  the  Exchange  of  Product  Model  Data  (STEP).  Part  11: 

EXPRESS 

ISO/IEC  10538  Information  Technology  -  Control  Functions  for  Text  Communication,  1991 

ISO/IEC  10388  Information  Technology  -  Use  of  the  X.29  PLP  in  Conjunction  with  X.21/X.21  Ms  to  Provide  the 

OSI  CONS,  1993 

ISO/IEC  10589*  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Intermediate  System  to  Intermediate  System  Intra-domain  Routing  Information  Exchange  Protocol 
for  Use  in  Conjunction  with  the  Protocol  for  Providing  the  Connectionless  Network  Service 
(ISO  8473),  1992 

ISO/IEC  ISP  10607-1*  Information  Technology  •  International  Standard  Profiler  AFT  no  -  File  Transfer,  Access  and 
Management,  Part  1:  Specification  of  ACSE,  Presentation  and  Session  Protocols  for  the  Use  by 
FTAM,  December  1990 

ISO/IEC  ISP  10607-1  DAM  1  Amendment  1:  Additional  Specifications  for  COBOL  Document  Types,  May  1993 
ISO/IEC  19  10607-2*  Information  Technology  •  International  Standard  Profiles  AFT  tut  -  File  Transfer,  Access  and 
Management,  Part  2:  Definition  of  Document  Type*,  Constraint  Sets  aid  Syntaxes,  December  1990 
(reprinted  April  1991  to  comet  error  in  Foreword) 
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BOIBC  BP  10«r7.2  DAM  I  ABMtenll:  ***m«Mi  TWi^iiM.  iw^  toot 

ISOABC  ISP  10607-2  DAM  2  Amendment  2:  Additional  Spacifications  far  COBOL  Document  Types,  May  1993 
ISOABC  BP  10607-2  DAM  3  Audit  3:  FTAM  Constraint  Set  and  Document  Type  far  CGM,  February  1993 
ISOABC  ISP  10607-3*  Information  Technology  -  International  Standard  Profile*  AFT  nn  -  File  Transfer,  Access  and 
Management,  Part  3:  AFT  11  -  Simple  File  Transfer  Service  (Unstructured),  December  1990 
(reprinted  April  1991  to  correct  error  in  Foreword) 

ISOABC  ISP  10607-4*  Intonation  Technology  -  International  Standard  Profiles  AFT  nn  -  File  Transfer,  Access  and 
Management,  Part  4:  AFT  12  •  Positional  File  Transfer  Service,  December  1991 
ISOABC  ISP  10607-4  DAM  1  Amendment  1:  Additional  Specification*  for  COBOL  Document  Types,  May  1993 
ISOABC  ISP  10607-5*  Information  Technology  -  International  Standard  Profiles  AFT  nn  -  File  Transfer,  Access  and 
Management,  Part  5:  AFT  22  •  Positional  File  Access  Service,  December  1991 
ISCWIEC  ISP  10607-5  DAM  1  Amendment  1:  Additional  Specification  for  COBOL  Document  Types,  May  1993 
ISOABC  ISP  10607-6*  Information  Technology  -  International  Standard  Profiles  AFT  nn  -  Hie  Transfer.  Access  and 
Management,  Part  6:  AFT  3  -  Hie  Management  Service,  December  1991 
ISOABC  ISP  10607-x  Information  Technology  -  International  Standard  Profiles  AFT  nn  -  File  Transfer,  Access  and 
Management,  Part  x:  AFT  13  •  Full  Hie  Transfer  (Hierarchical),  Draft,  1993 
ISOABC  ISP  10607-y  Information  Technology  -  International  Standard  Profiles  AFT  nn  -  File  Transfer,  Access  and 
Management,  Part  y:  AFT  23  -  Full  Hie  Access  (Hierarchical),  Draft,  1993 
ISOABC  ISP  10607-z  Information  Technology  -  International  Standard  Profiles  AFT  nn  -  File  Transfer,  Access  and 
Management,  Part  c  AFT  4  -  Filestore  Management  Profiles,  Draft,  1993 
ISOAEC  ISP  10606-1*  Information  Technology  -  International  Standardized  Profiles  TA  nnnn  -  Connection-mode 
Transport  Service  over  Connectionless-mode  Network  Service,  Part  1:  General  Overview  and 
Subnetwork-Independent  Requirements,  1992 

ISOAEC  ISP  10606-2*  Information  Technology  -  International  Standardized  Profiles  TA  nnnn  -  Connection-mode 
Transport  Service  over  Connectionless-mode  Network  Service,  Part  2:  TA51  Profile  Including 
Subnetwork-Dependent  Requirements  for  CSMA/CD  Local  Area  Networks,  1992 
DBF  10606-3  Information  Technology  -  International  Standardized  Profiles  TA  nnnn  -  Connection-mode 

Transport  Service  over  Connectionless-mode  Network  Service.  Part  3:  TA  52,  LAN,  Token  Bus: 
CLNS,  1993 

ISOAEC  ISP  10606-4*  Information  Technology  -  International  Standardized  Profile  TA  nnnn  -  Connection-mode 
Transport  Service  over  Connectionless-mode  Network  Service,  Past  4:  TA53,  LLC1,  Token  Ring 
LAN.  1993 

ISOABC  ISP  10606-5*  Information  Tecbno’  igy  -  International  Standardized  Profiles  TA  nnnn  -  Connection-mode 
Transport  Service  over  Connectionless -mode  Network  Service,  Part  5:  TA111 1/TA1121  Profiles 
Including  Subnetwork-Dependent  Requirements  for  X.25  Packet  Switched  Data  Networks  Using 
Switched  Virtual  Circuits,  1992 


Information  Technology  -  International  Standardized  Profiles  TA  nrmn  -  Connection-mode 
Transport  Service  over  Connectionless  Network  Service,  Part  6:  TA54  Profile,  FDDI  LAN 
Subnetwork,  1993 

Information  Technology  -  International  Standardized  Profiles  TA  nnnn  -  Connection-mode 
Transport  Service  over  Connectionless  Network  Service,  Part  13:  LAN -Dependent  Requirements  for 
Taken  Ring  MAC  and  PHY 

Information  Technology  -  International  Standardized  Profiles  TA  nrmn  -  Connection-mode 
Transport  Service  over  Connectionless  Network  Service,  Part  14:  MAC,  PHY,  PMD  Sublayer 
Dependent  State  Management  Requirements  over  FDDI  LAN  Subnetwork 

ISOAEC  ISP  10609-1  Information  Technology  -  International  Standardized  Profiler  IB,  TC,  TD.  and  IE  -  Conoection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  1:  Subnetwork-type 
Independent  Requirements  for  Group  IB,  1992 

ISOABC  ISP  10609-2*  Information  Technology  •  International  Standardized  Profiles  IB.  TC.  TD.  and  IE  -  Cormection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  2:  Subnetwork-type 
Independent  Requirements  for  Group  TC,  1992 

ISOAEC  ISP  10609-3  Information  Technology  -  International  Standardized  Profiles  TB,  TC,  ID,  and  IE  -  Connection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  3:  Subnetwork -type 
Independent  Requirements  for  Group  TD,  1992 

ISOABC  BP  10609-4  Information  Technology  -  International  Standardized  Profiles  TB,  TC.  TD,  and  TE  -  Connection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  4:  Subnetwork-type 
Independent  Requirements  for  Group  TE,  1992 

ISOABC  BP  10609-5  Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connection¬ 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  5:  Definition  of  Profile  TB 
1111/TB  1121  (Psraneot  Access  via  PSTWDifital  Data  Circuit  or  CSDN,  respectively.  Leased  Line, 
Virtual  Call,  Transport  Protocol  Classses  0,  2,  and  4),  1992 

ISOABC  ISP  10609-6*  Information  Technology  -  International  Standardized  Profiles  TB.  TC,  TD.  and  TE  •  Coonsction- 

mode  Transport  Service  over  Connection-mode  Network  Service,  Part  6:  Definition  of  Profile 
TC  UU/rc  1121  (Parana nt  Access  via  PSTNAJigital  Data  Circuit  or  CSDN.  respectively.  Leased 
Line,  Virtual  Call,  Transport  Protocol  Classses  0  and  2),  1992 


DBP  10606-6* 

MSP  10606-13 

MSP  10606-14* 
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ISQrtEC  ISP  10609-7 

ISO/IECISP  10609-8 

ISOrtEC  ISP  10609-9* 

pDISP  10609-10 
pMSP  10609-11 
pDISP  10609-12 
pDISP  10609-13 
pDiSP  10609-14 
pDISP  10609-20 

pDISP  10609-21 

pDISP  10609-22 

pDISP  10609-23 

pWSP  10609-24 

pMSP  10609-25 

pMSP  10609-26 

pMSP  10609-27 

pMSP  10609-2S 


Information  Technology  •  International  Standardized  Profile*  TB,  TC,  TO,  and  TE  •  Connection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  7:  Definition  of  Profile 
TO  1111/TO  1121  (Peranent  Access  via  PSTN/Digital  Dau  Circuit  or  CSDN,  respectively,  Leased 
Line,  Virutal  Call,  Transport  Protocol  Class*  0).  1992 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TO,  and  TE  -  Coonection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  8:  Definition  of  Profile 
TE  Ull/TE  1121  (Peranent  Access  via  PSTN/Digital  Data  Circuit  or  CSDN,  respectively.  Leased 
Line,  Virutal  Call  Transport  Protocol  Class*  2).  1992 
Information  Technology  •  International  Standardized  Profiles  TB,  TC,  TO,  and  TE  -  Connection¬ 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  9:  Subnetwork-type 
Dependent  Requirements  for  Network  Layer,  Data  Link  Layer,  and  Physical  Layer  Concerning 
Permanent  Access  to  a  Packet  Switched  Data  Network  Using  Virtual  Call,  1992 
Information  Technology  -  International  Standardized  Profile*  TB,  TC.  TO,  and  TE  -  Connection- 
inode  Transport  Service  over  Connection  -mode  Network  Service,  Part  10:  LAN  Subnetwork- 
Dependent  Media-Independent  Requirement*,  1993 

Information  Technology  -  International  Standardized  Profile*  TB,  TC,  TO,  and  TE  •  Connection- 
inode  Transport  Service  over  Connection-mode  Network  Service,  Part  11:  LAN  Subnetwork- 
Dependent  Media-Dependent  Requirements,  1993 

Information  Technology  •  International  Standardized  Profiles  TB,  TC,  TO,  and  TE  -  Connection- 
inode  Transport  Service  over  Connection-mode  Network  Service,  Part  12:  TCS1  Profile.  LLC2, 
CSMA/CD  LAN  •  Trnaaport  Protocol  Classes  0  and  2, 1993 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TO,  and  TE  •  Connection- 
inode  Transport  Service  over  Connection-mode  Network  Service,  Pert  13:  TCS3  Profile,  LLC2, 
Token  Ring  LAN  -  Trnaaport  Protocol  Classes  0  and  2,1993 

Information  Technology  •  International  Standardized  Profiles  TB,  TC,  TO,  and  TE  -  Coooectioo- 
mode  Transport  Service  over  Connection-mode  Network  Service.  Part  14:  COTS  Classes  0  and  2, 
CONS.  LLC2.  Token  Ring  LAN.  1993 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TO,  and  TE  •  Connection¬ 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  20.  TC/TO  nun.  Overview 
of  the  Generalized  Multipart  ISP  structure  for  TC  and  TO  Group  Profiles  for  OSI  Usage  of  ISDN. 
February  1993  (review  ended  June  1993) 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TO,  and  TE  -  Connection¬ 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  21:  TC/TDnnnn, 
Subnetwork  Type  Dependent  Requirements  for  Network  Layer  and  Data  Link  Layer  Concerning  End 
Systems  Attached  to  an  ISDN  Subnetwork  for  B -Channel  X.25  DTE-to-DTE  Operation.  February 
1993  (review  ended  June  1993) 

Information  Technology  •  International  Standardized  Profiles  TB,  TC.  TO.  and  TE  -  Connection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  22:  TC/TDnnnn. 
Subnetwork  Type  Dependent  Requirements  for  Network  Layer  and  Data  Link  Layer  Concerning  End 
Systems  Attached  to  an  ISDN  Subnetwork  for  B -Channel  X.25  DTE-to-DCE  Operation,  February 
1993  (review  ended  June  1993) 

Information  Technology  -  International  Standardized  Profiles  TB.  TC,  TO,  and  TE  -  Connection- 
mod e  Transport  Service  over  Connection-mode  Network  Service,  Part  23:  TC/TDnnnn, 
Subnetwork  Type  Dependent  Requirements  for  Network  Layer  and  Data  Link  Layer  for  Data  Transfer 
Concerning  Packet-Switched  Mode  ISDN  Virtual  Calls:  B -Channel  Access  Case,  February  1993 
(review  ended  June  1993) 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TO.  and  TE  -  Connection¬ 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  24:  TC/TDnnnn, 
Subnetwork  Type  Dependent  Requirements  for  Network  Layer  Using  Q.931  -  Circuit-Switched  Case, 
February  1993  (review  ended  Jane  1993) 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TO,  and  TE  -  Cormection- 
modc  Transport  Service  over  Connection-mode  Network  Service,  Part  25:  TC/TDnnnn, 
Subnetwork  Type  Dependent  Requirement*  for  Network  Layer  for  Call  Control  Procedures 
Concerning  the  Outgoing  Call  of  a  Packet-Switched  Mode  ISDN  in  Case  B  Using  Virtual  Calls, 
February  1993  (review  ended  June  1993) 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TO,  and  TE  -  Coonectkm- 
mode  Transport  Service  over  Connection -mode  Network  Service,  Part  26:  TC/TDnnnn, 
Subnetwork  Type  Dependent  Requirements  for  Network  Layer  for  Call  Cootrol  Procedures 
Concerning  the  Outgoing  Call  of  a  Packet-Switched  Mode  ISDN  in  Case  B  Using  Virtual  Calls. 
February  1993  (review  ended  Jane  1993) 

Information  Technology  •  International  Standardized  Profiles  TB,  TC,  TO,  and  TE  -  Connection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  27:  TC/TD  nnan. 
Subnetwork  Type  Dependent  Requirements  for  Network  Layer  for  Call  Cootrol  Procedures 
Concerning  the  Incoming  Cell  of  a  Packet-Switched  Mode  ISM)  in  Case  B  Using  Virtual  Calls, 
February  1993  (review  ended  June  1993) 

Information  Technology  -  International  Standardized  Profiles  TB.  TC,  TO,  and  TE  -  Counectkm- 
mods  Transport  Service  over  Connection-mode  Network  Service,  Part  28:  TC/TO  nun. 
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pDISP  10609-29 

pDISP  10609-30 

1XSP  10609-31* 

rasp  10609-32* 

rasp  10609-33* 

rasp  10609-34* 

rasp  10609-35* 

rasp  10609-36* 

rasp  10609-37* 

rasp  10609-38* 

pDISP  10609-40 

pDISP  10609-41 

pDISP  10609-42 

pDISP  10609-43 

pDISP  10609-44 

pDISP  10609-45 

pDISP  10609-46 
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Subnetwork  Type  Dependent  Roqwhtments  for  Deta  Lint  Layer  for  End  Systems  Attached  to  ip  ISDN 
Subnetwork,  February  1993  (review  ended  June  1993) 

Information  Technology  •  International  Standardized  Profile*  TB,  TC,  TD,  and  IB  -  Connection- 
mode  Tranaport  Service  over  Connection-mode  Network  Service,  Part  29:  TC  1131,  ISDN  B- 
Virtual  Call,  Permanent  Acceu  to  a  PSDN  •  Tranaport  Protocol  Claaaea  0  and  2,  February 
1993  (review  ended  Jane  1993) 

Information  Technology  -  International  Standardised  Profiles  TB.  TC.  TD,  and  TE  -  Connection- 
mode  Tranaport  Service  over  Connection-mode  Network  Service,  Part  30:  TC  1131.  ISDN  B- 
Channel  Virtual  Call,  Switched  Access  to  a  PSDN  -  Transport  Protocol  Classes  0  and  2,  February 
1993  (review  ended  June  1993) 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connection¬ 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  31:  TC  1231,  ISDN 
B -Channel  Virtual  Call,  Switched  Access  to  a  PSDN  •  Transport  Protocol  Classes  0  and  2, 1993 
Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD,  and  TB  -  Connection- 
mode  Transport  Service  over  Connection -mode  Network  Service,  Part  32:  TC  4111,  ISDN 
B -Channel  X.25  DTE  to  DTE,  Semi-permanent  Service  -  Transport  Protocol  Classes  0  and  2, 1993 
Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  33:  TC  4112,  ISDN 
B-Channel  X.25  DTE  o  DTE,  Circuit-mode  Service  -  Transport  Protocol  Classes  0  and  2, 1993 
Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connection¬ 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  34:  TC  43111,  ISDN 
D-Channel  Access  Virtual  Call.  Packet-mode  Service,  Without  Q.931  -  Transport  Protocol  Classes  0 
and  2.  1993 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  35:  TC  43112,  ISDN 
D-Channel  Access  Virtual  Call,  Packet-mode  Service,  with  Q.931  -  Transport  Protocol  Classes  0 
and  2.  1993 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connection- 
mode  Transport  Service  over  Connection-mode  Network  Service.  Part  36:  TC  43211,  ISDN 
B -Channel  Permanent  Access  Virtual  Call,  Packet-mode  Service,  Without  Q.931  -  Transport 
Protocol  Classes  0  and  2,  1993 

Information  Technology  -  International  Standardized  Profiles  TB.  TC.  TD.  and  TE  -  Connection¬ 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  37:  TC  43212,  ISDN 
B -Channel  Permanent  Access  Virtual  Call,  Packet-mode  Service,  with  Q.931  -  Transport  Protocol 
Classes  0  and  2. 1993 

Information  Technology  -  International  Standardized  Profiles  TB.  TC,  TD.  and  TE  -  Connection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  38:  TC  4331,  ISDN 
B -Channel  Demand  Access  Virtual  Call,  Packet-mode  Service  -  Transport  Protocol  Classes  0  and  2, 
1993 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD.  and  TE  -  Connection- 
mode  Transport  Service  over  Connection-mode  Network  Service.  Part  40:  TD  1131,  ISDN  B- 
Channel  Virtual  Call,  Permanent  Access  to  a  PSDN  -  Transport  Protocol  Class  0.  February  1993 
(review  ended  June  1993) 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connection- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  41:  TD  1231.  ISDN  B- 
Channel  Virtual  Call,  Switched  Acceu  to  a  PSDN  -  Transport  Protocol  Clue  0,  February  1993 
(review  ended  June  1993) 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD.  and  TE  -  Connection- 
mode  Transport  Service  over  Connection -mode  Network  Service,  Part  42:  TD41U,  ISDN  B- 
Channel,  X.25  DTE-to-DTE,  Semi-Permanent  Service  -  Transport  Protocol  Class  0,  February  1993 
(review  ended  June  1993) 

Information  Technology  •  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Conoectioo- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  43:  TD  4211,  ISDN  B- 
ChanneU  X.25  DTE-to-DTE,  Circuit-mode  Service  -  Transport  Protocol  Clau  0.  February  1993 
(review  ended  June  1993) 

Information  Technology  •  International  Standardized  Profiles  TB,  TC,  TD.  and  TE  -  Connection- 
mode  Transport  Service  over  Coooectioo-mode  Network  Service,  Part  44:  TD  43111,  ISDN  D- 
Channel  Access  Virtual  Call,  Packet-mode  Service,  Without  Q.931  •  Transport  Protocol  Classes  0, 
February  1993  (review  ended  June  1993) 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Coonectioo- 
motie  Transport  Service  over  Connection-mods  Network  Service,  Part  45:  TD  43112,  ISDN  D- 
Channel  Access  Virtual  Call,  Packet-mode  Service,  With  Q.931  -  Transport  Protocol  Classes  0, 
February  1993  (review  ended  June  1993) 

Information  Technology  •  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connection- 
nude  Transport  Service  over  GooaectioiMnode  Network  Service,  Part  46:  TD  43211,  ISDN  B- 
Channtl  Permanent  Acceu  Virtual  Can,  Packet-mode  Service,  Without  Q.931  •  Transport  Protocol 
Cl  esses  0,  February  1993  (review  ended  June  1993) 
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pDISP  10609-47 

pDISP  10609-48 

ISOflEC  ISP  10610-1 
DISP  10611-1* 

MSP  10611-2* 

DISP  10611-3* 

MSP  10611-4* 

IXSP  10611-5* 

IXSP  10612-1 

IXSP  10612-2 

pDISP  10612-3 

DISP  10612-4* 

piXSP  10612-3 

pIXSP  10612-6 

piXSP  10612-7 

pMSP  10612-8 

piXSP  10612-9 

piXSP  10613-1* 

pDISP  10613-2* 

pDISP  10613-3* 

IXSP  10613-4 

pDISP  10613-S* 
pDISP  10613-6 
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Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Coonectioo- 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  47:  TD  43212,  ISDN  B- 
rTmimi,  Permanent  Access  Virtual  Call,  Packet-mode  Service,  With  Q.931  -  Transport  Protocol 
Classes  0,  February  1993  (review  ended  June  1993) 

Information  Technology  -  International  Standardized  Profiles  TB,  TC,  TD,  and  TE  -  Connection¬ 
mode  Transport  Service  over  Connection-mode  Network  Service,  Part  48:  TD  43212,  ISDN  B- 
Channel,  Demand  Access  Virtual  Call,  Packet-mode  Service  -  Transport  Protocol  Classes  0, 
February  1993  (review  ended  June  1993) 

Information  Technology  -  International  Standardized  Profile*  FOD  nn.  Part  1:  FOD  11  Profile. 
Simple  Document  Structure  -  Character  Content  Only,  April  1992 

Information  Technology  •  International  Standardization  Profile*  AMHln  -  Message  Handling 
Systems  •  Common  Messaging.  Part  1:  MHS  Service  Support,  1993 

Information  Technology  -  International  Standardization  Profiles  AMHln  -  Message  Handling 
Systems  -  Common  Messaging,  Pari  2:  Specification  of  ROSE,  RTSE,  ACSE,  Presentation,  and 
Session  Protocols  for  Use  by  MHS,  1993 

Information  Technology  -  International  Standardization  Profiles  AMHln  -  Message  Handling 

Systems  •  Common  Messaging,  Part  3:  AMH11:  Message  Transfer  (PI),  1993 

Information  Technology  -  International  Standardization  Profiles  AMHln  -  Message  Handling 

Systems  -  Common  Messaging,  Pari  4:  AMH12:  MTS  Access  (P2),  1993 

Information  Technology  -  International  Standardization  Profiles  AMHln  -  Message  Handling 

Systems  -  Common  Messaging.  Pant  5:  AMH13:  MS  Access  (P7),  1993 

Information  Technology  -  International  Standardized  Profiles  RD  nn.nn  -  Relaying  the  MAC 
Service  Using  Transport  Bridging,  Part  l:  RD  5p3q  Profile,  Relaying  MAC  Using  Transparent 
Bridging  -  General  Overview  and  Subnetwork-Independent  Requirements.  1993 
Information  Technology  -  International  Standardized  Profiles  RD  nn.nn  -  Relaying  the  MAC 
Service  Using  Transport  Bridging,  Pari  2:  RD  3p3q  Profile,  CSMA/CD  LAN  Subnetwork- 
Dependent  Media-Dependent  Requirements,  1993 

Information  Technology  -  International  Standardized  Profiles  RD  nn.nn  -  Relaying  the  MAC 
Service  Using  Transport  Bridging,  Part  3:  RD  5p-5q  Profile,  Token  Ring  LAN  Subnetwork- 
Dependent  Media-Dependent  Requirements,  May  1993  (balloting  ended  September  1993) 
Information  Technology  -  International  Standardized  Profiles  RD  nn.nn  -  Relaying  the  MAC 
Service  Using  Transport  Bridging,  Part  4:  RD  51.51  Profile,  CSMA/CD  LAN  -  CSMA/CD  IAN, 
1993 

Information  Technology  -  International  Standardized  Profiles  RD  nn.nn  -  Relaying  the  MAC 
Service  Using  Transport  Bridging,  Part  5:  RD  S1.S4  Profile,  CSMA/CD  -  FDDL  May  1993 
(balloting  ended  September  1993) 

Information  Technology  -  International  Standardized  Profiles  RD  nn.nn  -  Relaying  the  MAC 
Service  Using  Transport  Bridging,  Part  6:  RD  54.54  Profile,  FDD!  -  FDDL  May  1993  (balloting 
ended  September  1993) 

Information  Technology  •  International  Standardized  Profiles  RD  nn.nn  -  Relaying  the  MAC 
Service  Using  Transport  Bridging.  Part  7:  RD  51.53  Profile,  CSMA/CD  IAN  -  Token  Ring  IAN. 
May  1993  (balloting  ended  September  1993) 

Information  Technology  -  International  Standardized  Profiles  RD  nn.nn  -  Relaying  the  MAC 
Service  Using  Transport  Bridging,  Part  8:  RD  53.53  Profile,  Token  Ring  LAN  -  Token  Ring  LAN, 
May  1993  (balloting  ended  September  1993) 

Information  Technology  -  International  Standardized  Profiles  RD  nn.nn  -  Relaying  die  MAC 
Service  Using  Transport  Bridging,  Part  9:  RD  5334  Profile,  Token  Ring  IAN  -  FDD!  LAN, 
May  1993  (balloting  ended  September  1993) 

Information  Technology  -  International  Standardized  Profiles  RA  nn.nn  -  Relaying  the 
Connectionless-mode  Network  Service,  Part  1:  Relay  Function,  Overview,  Snbnetwork-Indepeoeat 
Requirements,  1993 

Information  Technology  -  International  Standardized  Profiles  RA  nn.nn  -  Relaying  the 
Connectionless-mode  Network  Service,  Part  2:  LAN  Suboetwork-Depdeodent,  Media-Independent 
Requirements,  1993 

Information  Technology  •  International  Standardized  Profiles  RA  nn.nn  •  Relaying  the 
Connectionless-mode  Network  Service,  Part  3:  CSMA/CD  IAN  Suboetwork-Dspeodent  Media- 
Indepeodent  Requirements,  1993 

Information  Technology  •  International  Standardized  Profiles  RA  nn.nn  -  Relaying  the 
Connectioaleee-mode  Network  Service,  Part  4:  FDD!  LAN  Subnetwork-Dependent  Media-Dependent 
Requirements,  1993  (review  ended  April  1993) 

Information  Tachnology  -  International  Standardized  Profiles  RA  nn.nn  -Relaying  tba 
Conoectiooleas-mode  Network  Service,  Part  5.  RA5131  Profile,  CSMA/CD  -  CSMA/CD,  1993 
Information  Technology  •  International  Standardized  Profiles  RA  nn.nn  •  Relaying  the 
Coooectiooless-mode  Network  Service,  Pvt  6:  RA  5134,  CSMA/CD  LAN  rod  FDD!  IAN,  1993 
(review  ended  April  1993) 
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pOISP  10613-7*  Information  Technology  -  International  Standardized  Profile*  RA  nn.no  -  Relaying  the 
Connection  leu- mode  Network  Service,  Part  7:  PSDN  Subnetwork -Dependent  Media-Dependent 
Virtual  Call  Permanent  Accem,  1993 

pDISP  10613-8*  Information  Technology  -  International  Standardized  Profile*  RA  nn.nn  -  Relaying  the 
Connectionleu-mode  Network  Service,  Part  8:  RAS1.1 1 11  Profile,  CSMA/CD  -  PSTN,  Permanent 
Access,  PSTN-Leased  Virtual  Call,  1993 

pDISP  10613-9*  Information  Technology  -  International  Standardized  Profiles  RA  nn.nn  -  Relaying  the 
Connectionless-mode  Network  Service,  Part  9:  RA51.1121  Profile,  CSMA/CD  -  PSTN,  Permanent 
Access,  CSDN- Leased  Virtual  Call,  1993 

pDISP  10614-1  Information  Technology  -  International  Standardized  Profiles  RC  nn.nn  -  Relaying  X.2S  PLP, 
Part  1:  General  Overview  and  Subnetwork-Independent  Requirements,  1993 
pDISP  10614-2  Information  Technology  -  International  Standardized  Profiles  RC  nn.nn  -  Relaying  X.23  PLP, 
Part  2:  LAN  Subnetwork-Dependent  Media-Independent  Requirements,  1993 
pDISP  10614-3  Information  Technology  -  International  Standardized  Profiles  RC  nn.nn  -  Relaying  X.25  PLP. 

Part  3:  CSMA/CD  LAN  Subnetwork-Dependent  Media-Dependent  Requirement*.  1993 
pDISP  10614-4  Information  Technology  -  International  Standardized  Prefiles  RC  man  -  Relaying  X.2S  PLP, 
Part  4:  PSDN  Subnetwork  Type  Dependent  Requirements,  1993 
MSP  10614-3*  Information  Technology  -  International  Standardized  Profiles  RC  nn.nn  -  Relaying  X.25,  Part  3, 

RCS1.11U,  CSMA/CD  -  PSDN  Permanent  Access  PSTN-Leased  Virtual  Circuit.  1993 
MSP  10614-6*  Information  Technology  -  International  Standardized  Profiles  RC  nn.nn  -  Relaying  X.23.  Past  6, 

RC51.U21,  CSMA/CD  -  PSDN  Permanent  Access  CSDN-Leaeed  Virtual  Circuit.  1993 
MSP  10613-1*  Information  Technology  -  International  Standardized  Profiles  ADI  nn  -  OSI  Directory.  Part  1: 

ADI  11,  DUA  Support  of  Directory  Access,  January  1993 

MSP  10613-2*  Information  Technology  -  International  Standardized  Profiles  ADI  nn  —  OSI  Directory,  Part  2: 
ADI  12,  DSA  Support  of  Directory  Access,  January  1993 

MSP  10613-3*  Information  Technology  -  International  Standardized  Profiles  ADI  nn  -  OSI  Directory,  Part  3: 

ADI  21,  DSA  Responder  Role.  July  1993 

MSP  10613-4*  Information  Technology  -  International  Standardized  Profiles  ADI  nn  -  OSI  Directory,  Part  4: 

AM  22,  DSA  Initiator  Role,  July  1993 

pDISP  10613-3  Information  Technology  -  International  Standardized  Profiles  ADI  nn  -  OSI  Directory.  Part  3: 

ADI  31,  DUA  Support  of  Distributed  Operations,  1993 

pMSP  10613-6  Information  Technology  -  International  Standardized  Profiles  ADI  nn  -  OSI  Directory,  Part  6: 

ADI  32,  DSA  Support  of  Distributed  Operations,  1993 

pDISP  10613-7  Information  Technology  •  International  Standardized  Profiles  ADI  nn  -  OSI  Directory,  Part  7: 

ADI  41,  Strong  Authentication,  1993 

MSP  10616  Information  Technology  -  International  Standardized  Profile  FDI  11  -  Directory  Data  Definitions  - 

Common  Directory  Use  (Normal),  September  1993 

ISO/IEC  10641  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Testing  of 

Implementations  of  Graphics  Standards,  1993 

ISQ/IEC  10646  Information  Processing  -  Multiple  Octet  Coded  Character  Set,  SC27,  14  November  1989 

(SC21  N  4627],  approved  June  1992 

ISQ/IEC  10728  Information  Resource  Dictionary  System  (IRDS)  Services  Interface,  April  1993 

ISO/IEC  10728  PDAM  1  Amendment  1:  C  Language  Binding.  June  1993  [SC21  N  8088] 

ISQ/IEC  10728  WDAM  2  Amendment  2:  Ada  Language  Binding,  September  1993  [SC21  N  8203]  (PDAM  expected 

July  1994) 

WD  10728.2  Information  Resource  Dictionary  System  (IRDS)  Services  Interface,  Edition  2, 1993  (NWI  Proposal 

October  1990;  CD  expected  July  1994) 

ISO/IEC  10729-1  Conformance  Test  Suite  for  the  Presentation  Protocol,  Part  1:  Test  Suite  Structure  and  Test 
Purposes  for  the  Presentation  Protocol,  SC21/WG6,  September  1993  [SC21  N  7872] 

DIS  10729-2  Conformance  Test  Suite  for  the  Presentation  Layer,  Part  2:  Test  Suite  for  ASN.l  Encodings  snd  Test 

Purposes  for  Presentation  Protocol  November  1993  [SC21  N  8232]  (IS  expected  September  1994) 
WD  10729-3  Conformance  Test  Suite  for  the  Presentation  Layer,  Part  3:  Common  Presentation  Abstract  Test 

Suite,  October  1991  (WD  expected  in  June  1994;  CD  October  1994;  DIS  October  1993;  IS  October 
1996) 

ISQ/IEC  TR  10730  Information  Technology  •  Open  Systems  Interconnection  •  Tutorial  on  Naming  and  Addressing, 
April  1993  [SC21  N  7460] 

ISQ/IEC  TR  10730 WDAM  1  Amendment  1:  Directory  Names,  June  1993  [SC21  N  7998]  (dependent  on  progression  of 
amendment  to  ISO/IEC  9834-1) 

ISO/IEC  10731*  Information  Technology  -  Open  Systems  Interconnection  •  Conventions  for  the  Definition  of  OSI 
Services,  1992  (ITU-TS  ballot  dosed  November  1993)  (X .2 10:1 993) 

ISQ/IEC  10732  Use  ofX.23  PLP  to  Provide  the  OSI  CONS  over  the  Telephone  Network,  1993 
ISO/IEC  10733*  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Elements  of  Management  Information  Related  to  OSI  Network  Layer  Standards,  1993 
PDTR  10734  Guideline*  for  Bridged  LAN  Source  Routing  Operation  by  End  Systems,  1991 

ISO/IEC  TR  10735  Standard  Group  MAC  Addresses,  1993 
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1SOABC  10736 

US  10736  PDAM  1 
ISOAEC  10737* 

ISCVIEC  TR  1073* 

ISCVIEC  10739-1 
ISCVIEC  10740-1 
ISCVIEC  10740-2 
nS  10742 

CD  10743 
ISCVIEC  10744 
ISCVIEC  10745* 

WD  10746-1 

CD  10746-23 
CD  10746-3.2 
WD  10746-4 

nS  10747* 

WD  10778 
ISCVIEC  10918-1 
DIS  10918-2 
WD  10918-3 
CD  10967-1 

WD  10967-2 

nS  10994 

ISCVTR  11065 
ISCVIEC  11072 
ISO  11103 
ISO  11104 
ISCVIEC  11131 

ns  11166-1 
ns  11166-2 

ISCVIEC  11172-1 
ISCVIEC  11172-2 
ISCVIEC  11172-3 
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Information  Technology  •  Open  Systems  Interconnection  -  Transport  Layer  Security  Protocol, 
October  1993 

Amendment  1,  Security  Association  Establishment  Protocol,  JTC1/SC6,  July  1991 
Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Specification  of  the  Elements  of  Management  Information  Related  to  OSI  Transport  Layer 
Standards,  1993 

Information  Technology  •  Local  and  Metropolitan  Area  Networks  -  Token  Ring  Access  Method  and 
Physical  Layer  Specifications  -  Recommended  Practice  for  Use  of  Unshielded  Twisted  Pair  Cable 
(UTP)  for  Token  Ring  Data  Transmission  at  4  Mbit/s,  1993  [ANSI/IEEE  802.5M991] 

Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Test  Suite  for  9041  - 
Virtual  Terminal  Basic  Class  Protocol,  Part  1:  Test  Suite  Structure  and  Test  Purposes,  1992 
Information  Technology  -  Text  and  Office  Systems  -  Referenced  Data  Transfer,  Part  1:  Abstract 
Service  Definition,  1993 

Information  Technology  -  Text  and  Office  Systems  -  Referenced  Data  Transfer,  Part  2:  Protocol 
Specification,  1993 

Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  • 
Specification  of  the  Elements  of  Management  Information  Related  to  OSI  Data  Link  Layer 
Standards,  1993 

Information  Technology  -  Standard  Music  Description  Language  (SMDL),  April  1991 
Information  Technology  -  Hypermedia/Time-based  Structuring  Language  (HyTime),  1992 
Information  Technology  -  Open  Systems  Interconnection  -  Upper  Layer  Security  Model, 
November  1993  (SC21  N  8334]  (X.803) 

Basic  Reference  Model  for  Open  Distributed  Processing,  Part  1:  Overview  and  Guide  to  Use 
(formerly  Overview,  now  merged  with  old  Part  4),  September  1993  [SC21  N  7053]  (CD  expected 
July  1994,  MS  in  January  1995,  and  IS  in  October  1996)  (X.901) 

Basic  Reference  Model  for  Open  Distributed  Processing,  Part  2:  Descriptive  Model.  August  1993 
[SC21  N  7988]  (MS  expected  February  1994  and  IS  November  1995)  (X.902) 

Basic  Reference  Model  for  Open  Distributed  Processing,  Part  3:  Prescriptive  Model,  August  1993 
[SC21  N  8125]  (DIS  is  expected  in  February  1994  and  IS  in  November  1995)  (X.903) 

Basic  Reference  Model  for  Open  Distributed  Processing,  Part  4:  Architectural  Semantics, 
Specification  Techniques  and  Formalisms,  August  1992  [SC21  N  7056]  (CD  text  expected 
July  1994,  DIS  in  January  1995,  and  IS  in  October  1996)  (X.904) 

Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Protocol  for  Exchange  of  Inter-Domain  Rooting  Information  Among  Intermediate  Systems  to 
Support  Forwarding  of  ISQ/IEC  8473  PDUs,  1993 

High-Speed  Integrated  Services  Networks  and  User/Network  Interface  to  High-Speed  Integrated 
Services  Networks 

Digital  Compression  and  Coding  of  Continuous-Tone  Still  Images,  Part  1:  Requirements  and 
Guidelines,  1993 

Digital  Compression  and  Coding  of  Continuous-Tone  Still  Images,  Part  2:  Compliance  Testing, 
1993  (IS  status  expected  March  1994) 

Digital  Compression  and  Coding  of  Continuous-Tone  Still  Images,  Part  2:  Extensions,  1993  (CD 
status  expected  December  1994,  DIS  in  April  1995,  and  IS  in  1996) 

Information  Technology  •  Programming  Languages,  Their  Environments  and  Systems  Software 
Interfaces  -  Language  Compatible  Arithmetic,  Part  1:  Integer  and  Floating  Point  Arithmetic, 
undergoing  second  review  (November  1992-January  1993) 

Information  Technology  -  Programming  Languages,  Their  Environments  and  Systems  Software 
Interfaces  -  Language  Compatible  Arithmetic,  Part  2:  Complex  Arithmetic  and  Mathematical 
Procedures 

Information  Technology  -  Data  Interchange  on  90  mm  Flexible  Disk  Cartridges  Using  MFM 
Recording  at  31  831  FTPRAD  on  80  Trades  on  Each  Side,  June  1991 
Industrial  Automation  Glossary,  1992 

Information  Technology  -  Computer  Graphics  •  Reference  Model  of  Computer  Graphics,  1992 

Space  Data  and  Information  Transfer  Systems  -  Radio  Metric  and  Orbit  Data,  1991 

Space  Data  and  Information  Transfer  Systems  -  Time  Code  Formats,  1991 

Financial  Transactions  •  Wholesale  Braking  Security  -  Sign-On  Authentication,  TC68/SC2,  1993 

Financial  Transactions  -  Wholesale  Banking  Security  •  Key  Management  by  Mews  of  Asymmetric 

Algorithms,  Part  1:  Principles,  Procedures,  and  Formats,  TC68/SC2,  1993 

Financial  Transactions  -  Wholesale  Banking  Security  -  Key  Management  by  Means  of  Asymmetric 

Algorithms,  Part  2:  Approved  Algorithms  Using  RSA  Cryptosystem,  TC68/SC2, 1993 

Information  Technology  -  Coding  of  Moving  Pictures  and  Associated  Audio  for  Digital  Storage 

Media  at  Up  to  about  15  Mbit/s,  Part  1:  Systems,  August  1993 

Information  Technology  -  Coding  of  Moving  Pictures  rad  Associated  Audio  for  Digit’ll  Storage 
Media  at  Up  to  shout  15  Mbit/s.  Part  2:  Video,  August  1993 

Information  Technology  •  Coding  of  Moving  Pictures  and  Associated  Audio  for  Digital  Storage 
Media  at  Up  to  about  15  Mbit/s,  Part  3:  Audio.  August  1993 
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CD  11172-4 

WD  11172-5 

WD  11179-13 
WD  11179-2.2 
DIS  11179-3 
DIS  11179-4 
CD  11179-5.2 
CD  11179-6 
ISO/IEC  ISP  111*1-1 
ISO/IEC  ISP  11182-1 
ISO/IEC  ISP  11 183-le 

ISO/IEC  ISP  11183-2* 

pDISP  11183-x 

pDISP  11184-1 
pDISP  11184-2 
pDISP  11184-3 
pDISP  11184-4 

pDISP  11184-5 

pDISP  11184-6 

pDISP  11184-1 
pDISP  11184-x 

DISP  11185-1 

DISP  11185-2 

DISP  11185-3 

DISP  11185-4 

DISP  11185-5 
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Information  Technology  -  Coding  of  Moving  Picture*  and  Associated  Audio  for  Digital  Storage 
Media  at  Up  to  about  1.5  Mbit/s,  Part  4:  Conformance  Testing,  November  1993  (DIS  expected 
March  1994,  IS  in  November  1994) 

Information  Technology  -  Coding  of  Moving  Pictures  and  Associated  Audio  for  Digital  Storage 
Media  at  Up  to  about  1.5  Mbit/s,  Part  5:  Technical  Report  on  Software  for  ISO/IEC  11172,  1993 
(CD  expected  March  1994,  DIS  in  July  1994,  and  IS  in  March  1995) 

Information  Technology  -  Coordination  of  Data  Elements,  Part  1:  Framework  for  the  Generation 
and  Standardization  of  Data  Elements,  November  1993  (new  WD  expected  March  1994) 

Information  Technology  -  Coordination  of  Data  Elements,  Part  2:  Classification  of  Concepts  for 
the  Identification  of  Domains,  November  1993  (new  WD  expected  March  1994) 

Information  Technology  -  Coordination  of  Data ,  Elements,  Part  3:  Data  Element  Attributes, 
November  1993  (balloting  ended  February  1994) 

Information  Technology  -  Coordination  of  Data  Elements,  Part  4:  Definition  of  Data  Elements, 
Janaury  1994 

Information  Technology  -  Coordination  of  Data  Elements,  Part  5:  Naming  Principles  for  Data 
Elements,  Janaury  1994 

Information  Technology  •  Coordination  of  Data  Elements,  Part  6:  Representation  of  Data  Elements 
(Types),  November  1993  (new  WD  expected  March  1994) 

Information  Technology  -  International  Standardized  Profile  FOD26  -  Enhanced  Document  Structure 
-  Character,  Raster  Graphics  and  Geometric  Graphics  Content  Architecture,  April  1992 
Information  Technology  -  International  Standardized  Profile  FOD36  -  Extended  Document  Structure  • 
Character,  Raster  Graphics  and  Geometric  Graphics  Content  Architecture,  April  1992 
Information  Technology  -  International  Standardized  Profiles  AOM  In  -  OSI  Management  - 
Management  Communications  Protocols,  Part  1:  Specification  of  ACSE,  Presentation  and  Session 
Protocols  for  the  Use  by  ROSE  and  CMISE,  Revised  Edition,  December  1992 
Information  Technology  -  International  Standardized  Profiles  AOM  In  -  OSI  Management  - 
Management  Communications  Protocols,  Part  2:  CMISE/ROSE  for  AOM  12,  Enhanced 
Management  Communications,  1993 

Information  Technology  -  International  Standardized  Profiles  AOM  In  -  OSI  Management  - 
Management  Communications  Protocols,  Part  x:  Development  of  PTS  for  CMIP  (AOM  11, 
AOM  12),  1993 

Information  Technology  -  International  Standardized  Profiles  FVT  Inn  -  Virtual  Terminal  Basic 
Class -Register  of  VTE  Profiles,  Parti:  FVT  121.  S-mode  Forms  VTE  Profile,  1993 
Information  Technology  -  International  Standardized  Profiles  FVT  Inn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VTE  Profiles.  Part  2:  FVT  122.  S-mode  Paged  VTE  Profile,  1993 
Information  Technology  -  International  Standardized  Profiles  FVT  Inn  -  Virtual  Terminal  Basic 
Class -Register  of  VTE  Profiles,  Part  3:  FVT  111.  A-mode  Telnet  Profile  (pDISP  expected  1995) 
Information  Technology  -  International  Standardized  Profiles  FVT  Inn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VTE  Profiles,  Part  4:  FVT  112.  A-mode  Scroll  VTE  Profile  (pDISP  expected 
1995) 

Information  Technology  •  International  Standardized  Profiles  FVT  Inn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VTE  Profiles,  Part  5:  FVT  113.  A-mode  CCITT  X3  PAD  Interworking  (pDISP 
expected  1995) 

Information  Technology  -  International  Standardized  Profiles  FVT  Inn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VTE  Profiles,  Part  6:  FVT  1 14.  A-mode  Transparent  VTE  Profile  (pDISP 
expected  1995) 

Information  Technology  -  International  Standardized  Profiles  FVT  Inn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VTE  Profiler,  Part  7:  FVT  115.  A-mode  Generalized  Telnet  VTE  Profile,  1993 
Information  Technology  •  International  Standardized  Profiles  FVT  Inn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VTE  Profiles,  Part  x:  FVT  FVT  121  rod  122:  S-mode  Forms  and  Paged  VTE 
Profiles,  1993 

Information  Technology  -  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  •  Register  of  VT  Control  Objects,  Part  1:  FVT  211,  FVT  212,  Sequenced  and  Unsequenced 
Application  Control  Objects,  August  1993 

Information  Technology  •  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Part  2:  FVT  213,  FVT  214,  Sequenced  and  Unsequenced 
Terminal  Control  Objects,  August  1993 

Information  Technology  -  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  •  Register  of  VT  Control  Objects,  Part  3:  FVT  215,  FVT  216.  Application  RIO  Record 
Locating  Control  Object  and  Terminal  RIO  Record  Notification  Control  Object,  August  1993 
Information  Technology  -  International  Standardized  Profiles  FVT  2m>  -  Virtual  Terminal  Basic 
Clast  -  Register  of  VT  Control  Objects,  Part  4:  FVT  217,  Horizontal  Tabulation  Control  Object, 
August  1993 

Information  Technology  •  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Part  5:  FVT  218,  Logical  Image  Control  Object, 
August  1993 
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DISP  11185-6 

DISP  11185-7 

IHSP  11185-8 

rasp  11185-9 

DISP  11185-10 

DISP  11185-11 
pDISP  11185-12 

pDISP  11185-13 

pDISP  11185-14 
pDISP  11185-15 
pDISP  11185-16 

pDISP  11185-17 
pDISP  11185-x 

pDISP  11186-1 

IXSP  11187-W 
IXSP  U187-2e 
prasp  11187-3 

pDISP  11187-4 

pDISP  11187-6 

pDISP  11187-7 

pDISP  11187-8 

pDISP  11187-9 

pDISP  11187-10 


Information  Technology  -  International  Standardized  Profiler  FVT  2nn  •  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Part  6:  FVT  219,  Status  Message  Control  Object, 
August  1993 

Information  Technology  -  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Part  7:  FVT  220,  Entry-Control  Control  Object, 
August  1993 

Information  Technology  -  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Part  8:  FVT  221,  Forms  Field  Entry  Instruction  Control 
Object  (FEICO)  No.  1,  August  1993 

Information  Technology  •  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Pan  9:  FVT  222,  Paged  Field  Entry  Instruction  Control 
Object  (FEICO)  No.  1.  August  1993 

Information  Technology  -  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  •  Register  of  VT  Control  Objects,  Part  10:  FVT  231,  Forms  Field  Entry  Pilot  Control  Object 
(FEPCO)  No.  1. 1993 

Information  Technology  -  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Part  11:  FVT  232,  Paged  Field  Entry  Pilot  Control  Object 
(FEPCO)  No.  1. 1993 

Information  Technology  -  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Part  12:  FVT  FVT  2116,  2117,  2118,  and  2119: 
Generalized  Telnet  Synchronization,  Signal,  Negotiation  and  Subnegotiation  Control  Objects 
(pDISP  expected  1995) 

Information  Technology  -  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Part  13:  FVT  2111,  Waiting  Time  Control  Object  (pDISP 
expected  1995) 

Information  Technology  -  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Part  14:  FVT  2112,  Printer  Control  Object,  1993 
Information  Technology  •  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Clan  -  Register  of  VT  Control  Objects,  Part  IS:  FVT  2113,  Field  definition  Control  Object,  1993 
Information  Technology  •  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Part  16:  FVT  21 14,  Terminal  Signal  Titles  Control  Object, 
1993 

Information  Technology  •  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  VT  Control  Objects,  Part  17:  FVT  21 15,  Form  Help  Text  Control  Object,  1993 
Information  Technology  -  International  Standardized  Profiles  FVT  2nn  -  Virtual  Terminal  Basic 
Class  •  Register  of  VT  Control  Objects,  Part  x:  FVT  251,  Terminal  Conditions  Control  Object, 
1993 

Information  Technology  -  International  Standardized  Profiles  FVT  3nn  -  Virtual  Terminal  Basic 
Class  -  Register  of  Assignment  Type  Definitions,  Part  1:  FVT  321,  Font  Assignment  Type  No.  1 
(DISP  expected  1995) 

Information  Technology  •  International  Standardized  Profiles  AVT  In.  AVT  2n  -  Virtual  Terminal 
Baaic  Clasa  -  Application  Profiles,  Part  1:  AVT  22,  S-mode  Forms  Application  Profile.  1993 
Information  Technology  -  International  Standardized  Profiles  AVT  In,  AVT  2n  -  Virtual  Terminal 
Basic  Class  •  Application  Profiles,  Part  2:  AVT  23,  S-mode  Paged  Application  Profile,  1993 
Information  Technology  •  International  Standardized  Profiles  AVT  In,  AVT  2n  -  Virtual  Terminal 
Basic  Class  -  Application  Profiles,  Part  3:  S-mode  ISPICS  Requirements  List  No.  1  (pDISP  expected 
1995) 

Information  Technology  -  International  Standardized  Profiles  AVT  In,  AVT  2n  -  Virtual  Terminal 
Baaic  Class  -  Application  Profiles,  Part  4,  S-mode  ISPICS  Requirements  (IPRL)  List  No.  1, 
Supporting  Layers  List  No.  1  (pDISP  expected  1995) 

Information  Technology  -  International  Standardized  Profiles  AVT  In,  AVT  2n  -  Virtual  Terminal 
Bask  Class  -  Application  Profiles,  Part  6:  AVT  13,  A-mode  Scroll  Application  Profile.  pDISP 
expected  1995- 

Information  Technology  -  International  Standardized  Profiles  AVT  In,  AVT  2n  -  Virtual  Terminal 
Basic  Class  •  Application  Profiles,  Part  7:  AVT  14,  A-mode  CCTTT  X.3  PAD  Application  Profile 
(pDISP  expected  1995) 

Information  Technology  -  International  Standardized  Profiles  AVT  In,  AVT  2n  -  Virtual  Terminal 
Bask  Class  -  Application  Profiles,  Part  8:  AVT  15,  A-mode  Transparent  Application  Profile  (pDISP 
expected  1995) 

Information  Technology  -  International  Standardized  Profiles  AVT  In,  AVT  2n  -  Virtual  Terminal 
Bask  Class  •  Application  Profiles,  Part  9:  AVT  16,  A-mode  Generalized  Telnet  Application  Profile, 
1993 

Information  Technology  -  International  Standardized  Profiles  AVT  In,  AVT  2n  -  Virtual  Terminal 
Bask  Class  -  AppUcation  Profiles,  Part  10:  AVT  17,  A-mode  ISPICS  Requirements  List  No.  1 
(pDISP  expected  1995) 
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pDISP  11188-1  Information  Technology  -  International  Standardized  Profiles  -  Common  Upper  Layer  Requirements, 

Pvt  1:  Basic  Connection  Oriented  Requirements.  July  1993 

pDISP  11  IIS- 2  Information  Technology  -  International  Standardized  Profiles  •  Common  Upper  Layer  Requirements. 

Part  2:  ROSE  Baaed  Requirements.  October  1993  (pDISP  status  expected  1995) 
pDISP  1 1 188-3  Information  Technology  •  International  Standardized  Profiles  -  Common  Upper  Layer  Requirements. 

Part  3:  Minimal  OSI  Upper  Layer  Facilities,  July  1993 

MSP  11189  Infonnatioo  Technology  -  International  Standardized  Profile  FDI2  -  Directory  Data  Definitions  - 

MHS  Use  of  Directory,  September  1993 

MSP  11190  Information  Technology  •  International  Standardized  Profile  FDI3  -  Directory  Data  Definitions  - 

FT AM  Use  of  Directory,  September  1993 

ISCMEC  11319  Information  Technology  •  8  mm  Wide  Magnetic  Tape  Cartridge  for  Information  Interchange  - 
Helical  Scan  Recording,  1993 

MS  11321  Information  Technology  -  3,81  mm  Wide  Magnetic  Tape  Cartridge  for  Information  Interchange  - 

Helical  Scan  Recording-  Data/DaU  Format,  June  1991 

ISCVIEC  11404  Information  Technology  -  Programming  Languages  -  Common  1  -anguage-Indcpendcnt  Data  Types 

(CUD),  1991 

ISOAEC  11544  Coded  Representation  of  Bi-level  and  i  imitaH  Bits -per -pixel  Still  Pictures,  1993 

ISCVIEC  11558  Information  Technology  •  Data  Compression  for  Information  Interchange  -  Adaptive  Coding  with 

Embedded  Dictionary,  DCLZ  Algorithm,  1992 

DIS  11568-1  Financial  Transactions  -  Retail  Banking  Security  -  Key  Management,  Part  1:  Introduction  to  Key 

Management,  TC68/SC6/WG6,  1993 

DIS  11568-1  Financial  Transactions  -  Retail  Banking  Security  -  Key  Management,  Part  1:  Introduction  to  Key 

Management,  TC68/SC6/WG6,  1993 

DIS  11568-2  Financial  Transactions  -  Retail  Banking  Security  -  Key  Management,  Part  2:  Key  Management 

Techniques  for  Symmetric  Ciphers,  TC68/SC6/WG6,  1993 

DIS  11568-3  Financial  Transactions  -  Retail  Banking  Security  -  Key  Management,  Part  3:  Key  Life  Cycle  for 

Symmetric  Ciphers,  TC68/SC6/WG6,  1993 

WD  11968-5  Financial  Transactions  •  Retail  Banking  Security  -  Key  Management,  Part  5:  Key  Management 

Techniques  for  Asymmetric  Ciphers,  TC68/SC6/WG6.  1993 

WD  11568-6  Financial  Transactions  -  Retail  Banking  Security  -  Key  Management,  Part  6:  Key  Life  Cycle  for 

Asymmetric  Ciphers,  TC68/SC6/WG6,  1993 

WD  11568-7  Financial  Transactions  -  Retail  Banking  Security  -  Key  Management,  Part  7:  Key  Management 

Schemes.  TC68/SC6/WG6.  1993 

CD  11568-8  Financial  Transactions  -  Retail  Banking  Security  -  Key  Management,  Part  8:  Key  Management 

Related  Data  Elements,  TC68/SC6/WG6. 1993 

ISCVIEC  11569  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  System!  - 

26-Pole  Interface  Connector  Mateability  Dimentions  and  Contact  Number  Assignments,  1993 
ISCVIEC  11570*  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Transport  Protocol  Identification  Mechanism,  1992 

CD  11571  Infonnatioo  Technology  •  Telecommunications  and  Information  Exchange  Between  Systems  - 

Addressing  in  Private  Integrated  Services  Digital  Network,  September  1991 
CD  11572  Infonnatioo  Technology  •  Telecommunications  and  Information  Exchange  Between  Systems  - 

Addressing  in  Private  Integrated  Services  Network  -  Circuit  Mode  Bearer  Services  -  Inter-Exchange 
Signalling  Procedures  and  Protocol,  September  1991 

CD  11573  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 

Synchronization  Methods  and  Technical  Requirements  for  Private  Integrated  Services  Networks, 
September  1991 

CD  11574  Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 

Private  Integrated  Services  Network  -  Circuit  Mode  64  kbit/s  Bearer  Services  -  Service  Definition  • 
Functional  Capabilities  and  Information  Flows,  September  1991 
DIS  11577*  Network  Layer  Security  Protocol  JTC1/SC6,  1993 

MS  11578-1*  Information  Technology  -  Open  Systems  Intercoonectioo  -  Remote  Procedure  Call  Part  1:  Model 

October  1993  (SC21  N  8212]  (IS  expected  September  1994) 

MS  11578-2*  Information  Technology  •  Open  Systems  Interconnection  •  Remote  Procedure  Call  Part  2:  Interface 

Definition  Notation,  October  1993  [SC21  N  8213]  (IS  expected  September  1994) 

MS  11578-3*  Information  Technology  -  Open  Systems  Interconnection  •  Remote  Procedure  Call  Part  3:  Service 

Definition,  October  1993  [SC21  N  8214]  (IS  expected  September  1994) 

MS  11578-4*  Information  Technology  •  Open  Systems  Interconnection  -  Remote  Procedure  Call  Part  4:  Protocol 

Specification,  October  1993  [SC 21  N  8215]  (IS  expected  September  1994) 

WD  11578-5  Information  Technology  -  Open  Systems  Interconnection  -  Remote  Procedure  Call,  Part  5:  PICS 

Proforma,  June  1991  [SC21  N  6111]  (formal  WD  expected  July  1993;  CD  December  1993;  MS  July 
1994;  IS  July  1995;  SC21  la  considering  canceling  project  in  the  absence  of  an  editor  and  WD) 

MS  11586-1  Information  Technology  -  Open  Systems  Interconnection  •  Generic  Upper  Layers  Security  (GULS), 

Pvt  1:  Overview,  Models  and  Notation,  October  1993  [SC 21  N  8182]  (initiation  of  ITU-TS 
approval  ballot  expected  November  1994)  (X.830) 
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DIS  1 1586-2 

DIS  11586-3 

DIS  11586-4 

WD  11586-5 

WD  11586-6 

CD  11587.2 

PDTR  11589 
?DTR  11590 
CD  11714 

US  11730 
ISOffEC  11756 
WD  11770-1 

CD  11770-2 

CD  11770-3 

DISP  12059-0 


MSP  12059-1* 


MSP  12059-2* 


MSP  12059-3* 

MSP  12059-4* 

MSP  12059-5* 

MSP  12059-6* 

MSP  12060-1* 

DISP  12060-2 

DISP  12060-3 

MSP  12060-4* 

DISP  12060-5* 
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Information  Technology  -  Open  Systems  Interconnection  -  Generic  Upper  Layers  Security  (GULS). 
Part  2:  Security  Exchange  Service  Element  (SESE)  Service  Definition,  October  1993  [SC21  N  8183] 
(initiation  of  ITU-TS  approval  ballot  expected  November  1994)  (X.831) 

Information  Technology  -  Open  Systems  Interconnection  -  Generic  Upper  Layers  Security  (GULS). 
Part  3:  Security  Exchange  Service  Element  (SESE)  Protocol  Specification,  October  1993 
[SC21  N  8184]  (initiation  of  ITU-TS  approval  ballot  expected  November  1994)  (X.832) 
Information  Technology  -  Open  Systems  Interconnection  -  Generic  Upper  Layers  Security  (GULS). 
Part  4:  Protecting  Transfer  Syntax  Specification.  October  1993  [SC21  N  8185]  (initiation  of  ITU- 
TS  approval  ballot  expected  November  1994)  (X.833) 

Information  Technology  -  Open  Systems  Interconnection  -  Generic  Upper  Layers  Security  (GULS). 
Part  5:  SESE  PICS  Proforma,  June  1993  [SC21  N  7912]  (CD  expected  July  1994;  initiation  of  ITU- 
TS  approval  ballot  expected  November  1994)  (X.834) 

Information  Technology  -  Open  Systems  Interconnection  -  Generic  Upper  Layers  Security.  Part  6: 
Protecting  Transfer  Syntax  -  PICS  Proforma,  June  1993  [SC21  N  7913]  (CD  expected  July  1994; 
initiation  of  ITU-TS  approval  ballot  expected  November  1994)  (X.835) 

Application  Context  for  Systems  Management  with  Transaction  Processing,  July  1993 
[SC21  N  7899]  (editing  meeting  February  1994;  initiation  of  ITU-TS  approval  ballot  expected 
June  1995)  (X.702) 

LOTOS  Description  of  the  CCR  Service,  June  1993  [SC21  N  7876} 

LOTOS  Description  of  the  CCR  Protocol,  June  1993  (SC 2 1  N  7877] 

General  Principles  for  the  Creation  of  Symbols  for  Use  in  Technical  Documentation  of  Products, 
September  1991 

Form  Interface  Management  System  (FIMS),  15  July  1992 
Information  Technology,  Programming  Languages  •  MUMPS,  1992 

Information  Technology  -  Security  Techniques  -  Key  Management,  Part  1;  Framework,  SC27/WG1, 
1993  [SC27  N  685] 

Information  Technology  -  Security  Techniques  -  Key  Management,  Part  2:  Key  Management 
Mechanisms  Using  Symmetric  Techniques,  SC27/WG2,  November  1992  [SC27  N  626] 
Information  Technology  -  Security  Techniques  -  Key  Management.  Part  3:  Key  Management 
Mechanisms  Using  Asymmetric  Techniques,  SC27/WG2,  1993 

Information  Technology  -  International  Standardized  Profiles  -  Management  Functions  -  Common 
Information  for  Management  Functions,  Part  0:  Common  Definitions  for  Management  Function 
Profiles,  December  1992  (ISP  expected  December  1993) 

Information  Technology  -  International  Standardized  Profiles  -  Management  Functions  -  Common 
Information  for  Management  Functions,  Part  1:  Object  Management,  December  1992  (ISP  expected 
December  1993) 

Information  Technology  -  International  Standardized  Profiles  •  Management  Functions  -  Common 
Information  for  Management  Functions.  Part  2:  State  Management,  December  1992  (ISP  expected 
December  1993) 

Information  Technology  -  International  Standardized  Profiles  -  Management  Functions  -  Common 
Information  for  Management  Functions,  Part  3:  Attributes  for  Representing  Relationships. 
December  1992  (ISP  expected  December  1993) 

Information  Technology  -  International  Standardized  Profiles  -  Management  Functions  -  Common 
Information  for  Management  Functions,  Part  4:  Alarm  Reporting,  December  1992  (ISP  expected 
December  1993) 

Information  Technology  •  International  Standardized  Profiles  -  Management  Functions  -  Common 
Information  for  Management  Functions,  Part  5:  Event  Report  Management,  December  1992  (ISP 
expected  December  1993) 

Information  Technology  •  International  Standardized  Profiles  -  Management  Functions  -  Common 
Information  for  Management  Functions,  Part  6:  Log  Control,  December  1992  (ISP  expected 
December  1993) 

Information  Technology  -  International  Standardized  Profiles  AOMura  -  OSI  Management  - 
Management  Functions,  Part  1:  AOM  211,  General  Management  Capability,  December  1992  (ISP 
expected  December  1993) 

Information  Technology  -  International  Standardized  Profiles  AOMnnn  •  OSI  Management  - 
Management  Functions,  Part  2;  AOM  212,  Alarm  Reporting  and  State  Management  Capabilities, 
December  1992  (ISP  expected  December  1993) 

Information  Technology  •  International  Standardized  Profiles  AOMnnn  -  OSI  Management  - 
Management  Functions,  Part  3:  AOM  213,  Alarm  Reporting  Capabilities,  December  1992  (ISP 
expected  December  1993) 

Information  Technology  -  International  Standardized  Profiles  AOMnnn  -  OSI  Management  • 
Management  Functions,  Part  4:  AOM  221,  General  Event  Report  Management,  December  1992 
(ISP  expected  December  1993) 

Information  Technology  •  International  Standardized  Profiles  AOMnnn  •  OSI  Management  • 
Management  Functions,  Part  5:  AOM  231,  General  Log  Control,  December  1992  (ISP  expected 
December  1993) 
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pDISP  12060-w 
pDISP  12060-x 

pDISP  12060-y 
pDISP  12060-z 

DISP  12061-1 
DISP  12061-2 
DISP  12061-3 
DISP  12061-4 
DISP  12061-S 
DISP  12061-6 
DISP  12061-7 

DISP  12061-8 

pDISP  12061-9 

pDISP  12061-10 

pDISP  12061-11 
pDISP  12061-x 
pDISP  12061 -y 
pDISP  12062-1 

pDISP  12062-2 

pDISP  12062-3 

pDISP  12062-4 

pDISP  12062-5 

pDISP  12063 
pDISP  12064-1 

pDISP  12065-1 

pDISP  12066-1 


Information  Technology  -  International  Standardized  Profiler  AOMnnn  •  OSI  Management  - 
Management  Function*.  Part  w:  AOM  242,  Security  Protocol*  (ISP  expected  November  1993) 
Information  Technology  -  International  Standardized  Profile*  AOMnnn  -  OSI  Management  - 
Management  Function*,  Part  x:  AOM  251,  General  Performance  Profile  (ISP  expected 
September  1994) 

Information  Technology  -  International  Standardized  Profile*  AOMnnn  •  OSI  Management  - 
Management  Functions,  Part  y:  AOM  252x,  Metric  Objects  (ISP  expected  May  1994) 

Information  Technology  •  International  Standardized  Profiles  AOMnnn  -  OSI  Management  - 
Management  Functions,  Part  z:  AOM  253x,  Summarization  Object*  (ISP  expected 
September  1994) 

Information  Technology  -  International  Standardized  Profiles  ATP  nn  •  OSI  Distributed  Transaction 
Processing,  Part  1:  Introduction  to  the  Transaction  Processing  Profiles,  July  1993 
Information  Technology  •  International  Standardized  Profiles  ATP  nn  •  09  Distributed  Transaction 
Processing,  Part  2:  Support  of  the  OSI  TP  APDUs,  July  1993 

Information  Technology  -  International  Standardized  Profiles  ATP  nn  -  OSI  Distributed  Transaction 
Processing,  Part  3:  Support  of  the  CCR  Protocol,  July  1993 

Information  Technology  -  International  Standardized  Profiles  ATP  nn  -  OSI  Distributed  Transection 
Processing,  Part  4:  Support  of  Session,  Presentation  and  ACSE  Protocols,  July  1993 
Information  Technology  -  International  Standardized  Profiles  ATP  nn  -  OSI  Distributed  Transaction 
Processing,  Part  5:  ATP  11,  Application-Supported  Transactions  with  Polarized  Control,  July  1993 
Information  Technology  -  International  Standardized  Profiles  ATP  nn  -  OSI  Distributed  Transaction 
Processing,  Part  6:  ATP  12,  Application-Supported  Transactions  with  Shared  Control,  July  1993 
Information  Technology  -  International  Standardized  Profiles  ATP  nn  -  OSI  Distributed  Transaction 
Processing,  Part  7:  ATP  21,  Provider-Supported  Transactions  in  Unchained  Mode  with  Polarized 
Control,  July  1993 

Information  Technology  -  International  Standardized  Profiles  ATP  nn  -  OSI  Distributed  Transaction 
Processing,  Part  8:  ATP  22,  Provider-Supported  Transactions  in  Unchained  Mode  with  Shared 
Control,  July  1993 

Information  Technology  -  International  Standardized  Profiles  ATP  nn  -  OSI  Distributed  Transaction 
Processing,  Part  9:  ATP  31,  Provider-Supported  Transactions  in  Chained  Mode  with  Polarized 
Control,  July  1993  (ballot  ended  November  1993) 

Information  Technology  -  International  Standardized  Profiles  ATP  nn  -  OSI  Distributed  Transaction 
Processing,  Part  10:  ATP  32,  Provider-Supported  Transactions  in  Chained  Mode  with  Shared 
Control,  July  1993  (ballot  ended  November  1993) 

Information  Technology  •  International  Standardized  Profiles  ATP  nn  -  OSI  Distributed  Transaction 
Processing,  Part  11:  TP  Transaction  Recovery  Application  Context,  September  1993 
Information  Technology  -  International  Standardized  Profiles  ATP  nn  -  OSI  Distributed  Transaction 
Processing,  Part  x:  Systems  Profiling  for  TP,  1993 

Information  Technology  -  International  Standardized  Profiles  ATP  nn  -  OSI  Distributed  Transaction 
Processing,  Part  y:  Development  of  PTS  for  TP,  1993 

Information  Technology  -  International  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems 

•  Interpersonal  Messaging,  Part  1:  IPM  MHS  Service  Support,  August  1993  (review  ended 
December  1993) 

Information  Technology  -  International  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems 

-  Interpersonal  Messaging,  Part  2:  AMH  21,  IPM  Content.  August  1993  (review  ended  December 
1993) 

Information  Technology  -  International  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems 

-  Interpersonal  Messaging,  Part  3:  AMH  22,  IPM  Requirements  for  Message  Transfer  (PI), 
August  1993  (review  ended  December  1993) 

Information  Technology  -  Internationa]  Standardized  Profiles  AMH  nn  -  Message  Handling  Systems 

-  Interpersonal  Messaging,  Part  4:  AMH  23,  IPM  Requirements  for  MTS  Access  (P3).  August  1993 
(review  coded  December  1993) 

Information  Technology  -  International  Standardized  Profiles  AMH  nn  •  Message  Handling  Systems 

•  Interpersonal  Messaging,  Part  5:  IPM  Requirements  for  Enhanced  MS  Access  (P7),  August  1993 
(review  ended  December  1993) 

Information  Technology  -  International  Standardized  Profiles  AMH  3  -  Message  Handling  Systems, 
1993 

Information  Technology  -  International  Standardized  Profiles  FOD  nnn  -  ODA  -  Open  Document 
Format  Image  Applications  -  Simple  Document  Structure  -  Raster  Graphics  Content  Architecture, 
Part  1:  POD  112,  Document  Applications  Profile,  August  1993  (balloting  ended  December  1993) 
Information  Technology  -  International  Standardized  Profiles  ALD  In  •  Library  and  Documentation  • 
Search  and  Retrieve,  Part  1:  Specification  of  ACSE,  Presentation,  and  Session  Protocols  for  Use  by 
Library  and  Documentation,  August  1993 

Information  Technology  -  International  Standardized  Profiles  ALD  2n  •  Library  and  Documentation  - 
Interlibrary  Loan,  Part  1:  Generic,  August  1993 
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pDESP  12066-2 

DIS  12087-1 
DIS  12087-2 

CHS  12087-3 
ISQflDBC  12119 
ISOflECTK  12178 
CD  12227 
ISQffECTK  12382 
WD  13182 
PDTR  13335-1 

WCTIK  13335-2 

WDIK  13335-3 

CD  13492 

CD  13522-1 

WD  13522-2 

WD  13522-3 

CD  13594 

CD  13642 

CHS  13712-1 

DIS  13712-1  FDAM1 
CHS  13712-2 

US  13712-2  PD  AMI 
nS  13712-3 

DIS  13712-3  PDAM1 
US  13712-4 

WD  13712-5 

DIS  13719-1 

DIS  13719-2 

US  13719-3 

CD  13818-1 

CD  13818-2 

CD  13818-3 

WD  13818-4 

WD  13818-5 
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Information  Technology  -  International  Standardized  Profiles  ALD  2n  -  Library  end  Documentation  - 

Interlibrary  Loan,  Part  2:  Using  CoonectkM-Orieated  ACSE,  August  1993 

Image  Processing  and  Interchange  (IP!)  Standard,  Part  1:  Common  Architecture  for  Imaging  (CAI) 

Image  Processing  and  Interchange  (IPI)  Standard,  Part  2:  Programmer's  Imaging  Kernel  System 

(PDCS) 

Image  Processing  and  Interchange  (IPI)  Standard,  Part  3:  Image  Interchange  Facility  (HP) 
Information  Technology  -  Software  packages  -  Quality  Requirements  and  Testing,  1993 
Uaer  Requirements  for  Systems  Supporting  Time -Critical  Communications.  December  1993 
SQL  Ada  Module  Description  Language  (SAMeDL) 

Permuted  Index  of  the  Vocabulary  of  Information  Technology,  1992 
Financial  Transactions  -  Security  Architecture  •  System  Overview,  TC68/SC6/WG7,  1993 
Information  Technology  -  Security  Techniques  -  Guidelines  for  Management  of  Information 
Technology  Security,  Part  1:  Concepts  and  Models,  SC27/WG1, 1993 

Information  Technology  •  Security  Techniques  -  Guidelines  for  Management  of  Information 
Technology  Security,  tat  2:  Managing  and  Planning,  SC27/WG1,  1993 

Information  Technology  •  Security  Techniques  -  Guidelines  for  Management  of  Information 
Technology  Security,  Part  3:  Techniques,  SC27/WG1, 1993 

Financial  Transactions  -  Retail  Banking  Security  -  Secure  Cryptographic  Devices.  TC68/SC6/WG6, 
1993 

Coding  of  Multimedia  and  Hypermedia  Information,  Part  1:  MHEG  Objects  Representation  -  Base 
Notation  (ASN.l).  1993  (DIS  expected  March  1994  and  IS  in  November  1994) 

Coding  of  Multimedia  and  Hypermedia  Information,  Part  2:  Alternate  Notation  (SMSL),  1993  (CD 
expected  March  1994,  IMS  in  November  1994,  and  IS  in  February  1995) 

Coding  of  Multimedia  and  Hypermedia  Information,  Part  3:  MHEG  Extensions  for  Scripting 
Language  Support  1993  (CD  expected  December  1994,  IMS  in  June  1995  and  IS  in  December  1995) 
Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Lower  Layers  Security  Model,  1993  (target  date  for  ITU-TS  approval  November  1994) 

Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Systems  - 
Specification  of  the  Elements  of  Management  Information  Related  to  OSI  Physical  Layer  Standards, 
1993 

Information  Technology  •  Open  Systems  Interconnection  -  Remote  Operations,  Part  1:  Model. 
1993  (X.880)  (initiation  of  ITU-TS  ballot  approval  February  1994)  (see  9072-1) 

Amendment  1:  Built-In  Operations,  Janaury  1994  [SC21  N  8406] 

Information  Technology  -  Open  Systems  Interconnection  •  Remote  Operations,  Part  2:  Service, 
1993  (X.881)  (initiation  of  ITU-TS  ballot  approval  February  1994)  (see  9072-2) 

Amendment  1:  Mapping  to  A-UNTTDATA  and  Built-In  Operations,  Janaury  1994  [SC21  N  8407] 
Information  Technology  -  Open  Systems  Interconnection  -  Remote  Operations.  Part  3:  Protocol, 
1993  (X.882)  (initiation  of  ITU-TS  ballot  approval  February  1994)  (see  9072-3) 

Amendment  1:  Mapping  to  A-UNTTDATA  and  Built-In  Operations,  Janaury  1994  (SC21  N  8408] 
Information  Technology  -  Open  Systems  Interconnection  -  Remote  Operations,  Part  4:  PICS 
Proforma,  1993  (X.883)  (initiation  of  ITU-TS  ballot  approval  November  1994)  (see  9072-4) 
Information  Technology  -  Open  Systems  Interconnection  -  Remote  Operations,  Part  5: 
Enhancements,  1993  (initiatioo  of  ITU-TS  ballot  approval  June  1995) 

Information  Technology  -  Portable  Common  Tools  Environment  (PCTE),  Part  1:  Abstract 
Specification  (ECMA-149),  September  1993 

Information  Technology  -  Portable  Common  Tools  Environment  (PCTE),  Part  2:  C  Programming 
language  Binding  to  PCTE  (ECMA-158),  September  1993 

Information  Technology  •  Portable  Common  Tools  Environment  (PCTE),  Part  3:  Ada  Programming 
Language  Binding  (ECMA-162),  September  1993 

Information  Technology  -  Generic  Coding  of  Moving  Pictures  and  Associated  Audio  Information, 
Part  1:  Systems,  SC29/WG11,  November  1993  [SC29  N  634]  (IMS  expected  March  1994.  IS  in 
November  1994] 

Information  Technology  -  Generic  Coding  of  Moving  Pictures  and  Associated  Audio  Information, 
Part  2:  Video,  SC29/WGU,  November  1993  [SC29  N  634]  (IMS  expected  March  1994,  IS  in 
November  1994] 

Information  Technology  •  Generic  Coding  of  Moving  Pictures  and  Associated  Audio  Information, 
Part  3:  Audio,  SC29/WG11,  November  1993  [SC29  N  635]  (IMS  expected  Match  1994.  IS  in 
November  1994] 

Information  Technology  -  Generic  Coding  of  Moving  Pictures  and  Associated  Audio  Information, 
Part  4:  Conformance  Testing,  SC29/WG11,  November  1993  [SC29  N  636]  (CD  expected  November 
1994,  DIS  in  March  1995,  IS  in  November  1995] 

Information  Technology  -  Generic  Coding  of  Moving  Pictures  and  Associated  Audio  Information, 
PartS:  Technical  Report  on  Software  for ISQfiEC  13818,  SC29/WG11  (WD  expected  July  1994,  CD 
fat  November  1994,  DIS  in  Match  1995,  IS  in  November  1995] 
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am  iuiu  hflaaMkn  Tectorfncv  •  Gwsric  Codtai  of  Moytai  RMNi  ad  AmcM  Aadto  Ubadtai. 

Part  6:  ^MaJSSSa.  SC29rtr011  (WD  mooted  Nouimhir  1994,  CD  in  March  1995.  DC  hi 
November  1993,  IS  in  July  1996] 

WD  13818-7  Information  Technology  •  Generic  Codiag  of  Moving  Pictures  ad  Arecrimad  Audio  ludnimstina. 

Part  7:  Audio  Extension*,  SC29/WG11  (WD  expected  November  1996,  CO  in  March  1997,  DC  in 
July  1997,  IS  in  March  1998] 

STANDING  AND  RELATED  DOCUMENTS 
Standing  Documents 

SIR'S  SD-1  Information  Technology  -  International  Standardized  Profiles  •  Taxonomy  Update,  ISP  Approval 

and  Maintenance  Process,  October  1993  [SGFS  N  1013] 

SGFS  SD-3  An  Informal  Quality  Service  for  Functional  Stnadarda  and  the  List  of  Informal  Review  Experts, 

August  1993  [SGFS  N  977] 

SGFS  SIM  Information  Technology  •  Framework  and  Taxonomy  of  International  Standardized  Profiles  - 

Directory  of  ISPs  and  Profiles  Contained  Therein,  SGFS  N  1049,  November  1993 
SGFSSD-7  Issues  List  far  Future  Development  of  ISOflEC  TR  10000,  SGFS  N  1023,  September  1993 

SC6  SIM  Directory  of  ISPs  and  Profiles  Contained  Therein,  February  1992 

SC21SD-1  Report  of  the  SC21  Secretariat,  SC21  Secretariat,  January  1993  [JTC1  N  2318] 

SC21SD-2  ISQ/IBC  JTC1 SC21  Programme  of  Wort  (POW)  -  Target  Date  Summary  far  All  Active  and  Publisher! 

Projects,  SC21  Secretariat,  October  1993  [  SC21  N  8082] 

SC21  SD-3  SC21  Inter-Project  Dependencies.  SC21  Secretariat,  May  1992  [SC21  N  6937) 

SC21  SIM  SC21  Strategic  Plan,  January  1992  [SC21  N  6711] 

SC21  SD-3  Rules  to  be  Applied  in  the  SC21  Editing  Proceed  November  1991  [SC21  N  6334] 

SC21SD-6  Directives  for  the  Work  of  JTC1.  Edition  2, 1992 

SC21  SD-7  Management  Plan  for  Security.  Edition  1.  June  1990  [SC21  N  3130] 

SC21  SD-8  SC21  Schedule  of  Meetings,  June  1993  [SC21  N  8084] 

SC21  SD-9  Approved  Commenuries  on  the  Basic  Reference  Model  for  Open  System  Interconnection.  OSI 

Reference  Model  Editor.  November  1991  [SC2I N  6198] 

SC21  SD-10  SC21/ITU-TS  Collaborative  Projects,  September  1993  [SC21  N  8083) 

SC21  SD-11  Management  Guidelines  far  SC21,  December  1999  [SC21  N  8362] 

Guidance 

SC21N7213  Maosgemeat  Guidelines  for  SC21.  Jane  1992  (to  be  updated  in  accorttenoe  with  SC21  N  8122) 

SC21N7489  Guide  for  lTU-TS(CCnT)  to  ISOflEC  JTC1  Coopantioa.  December  1992  (Annex  K  to  We  ISOflEC 

JTC1  Directives,  JTC1  N  2119) 

9C21N8U6  Final  Steps  for  the  Editing  of  Stemtatds  in  tee  Case  of  Collaborative  Work  with  ITU-TS,  June  1993 

SC21  N  8080  Guidelines  far  Conducting  Editing  Meetings  Using  Electronic  Mail.  June  1993 

SC21N8132  Identification  of  Versions  in  the  Foreword  of  a  Standard.  June  1993 

SC21N8024  Programme  of  Work  of  ISOflEC  JTC1/SC21SWG1,  June  1993 

Report  to  1994  JTC1  Plenary: 

JTC1  N  2707  Proposed  Modifications  to  the  ISOflEC  JTC1/SC21  Programme  of  Work,  Secretariat,  ISOflEC 

JTC1/SC21,  November  1993 

JTC1  N  2777  Report  of  JTCUSC21  to  the  1994  JTC1  Plenary  Meeting  in  Washington,  DC,  Secretariat,  ISOflEC 

JTCI/SC21.  December  1993 

JTTC1  N  2831  Management  Report  of  JTC1/SC21  to  the  1994  JTC1  Plenary  Meeting  in  Washington.  DC, 

Chairman,  ISOflEC  JTC1/SC21,  January  1994 

Reporta,  Resolutions,  and  Racommendatlona  from  SCSI  Plenary  Meetings 

SC2I  N  7978  Rationale  for  Propoead  SC21/WG4  Program  Exteacione.  SC21/W04,  July  1993 

SC21  N  7979  Report  of  the  Tenth  ISOflEC  JTCI/SC21/WG4  Meeting.  Yokohama.  13-24  Jane  1993.  SC21/WG4, 

September  1993 

SC21  N  8021  Report  of  the  ISOflEC  JTC1/SC21/WG1  Meeting,  Yokohama,  16-24  Jane  1993,  SC21/WG1. 

September  1993 

SC21N8024  ISOflEC  JTC1/SC21/WG1  Programme  of  Worir.  SC21/WG1.  July  1993 

SC21  N  8028  List  of  Late  Contributions  and  Output  Documents  of  the  SC21/WG1  Yokohama  Meeting, 

16-24  June  1993,  SC21/WG1,  July  1993 

SC21  N  8081  Reeotutioot  erf  the  Ninth  Plenmy  Meeting  of  ISOflEC  JTC1/SC  21.  29-30  June  1993.  Yokohama, 

Japan,  June  1993 

SC21  N  8217  Report  of  the  SC21/WG7  Meeting,  June  1993,  Yokohama.  SC21/WG7.  September  1993 

SC21  N  8027  Reeotutions  of  SC21/WG1,  June  1993 

SC21  N  8123  Reeolutioas  of  SC21/WG3,  June  1993 

SC21  N  7977  Resolutions  of  SC21/WG4,  June  1993 

SC21  N  8053  Reeolutioas  of  SC21/WG7,  Jane  1993 

SC21  N  8078  Resototioas  of  SC21/WG8,  Jans  1993 

SC21  N  SOB 3  Convenor's  Report  for  SC21/WG1,  June  1993 

SC21  N  8113  Convenor's  Report  for  SC21/WG3,  toe  1993 
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SC21  N  MM3  Coavtaor'i  Report  for  SC21/WG4,  June  1993 

SC21  N  1124  Convenor's  Report  for  SC2UWG7.  lone  1993 

SC21  N 1079  Convenor' i  Report  for  SC21/WG8,  lone  1993 

rrgional  Workshop  technical  reports 

BWOS  OoMeMaet  for  Jrianaged  Object  Profiting  end  Taxonomy.  September  1993  (RWS-TR  expected 

February  1994) 

BWOS  Framework  for  Confetmroes  Totting  of  Network  Management  Profilet,  September  1993  (RWS-TR 

expected  Ftbraary  1994) 

BWOS  Tutorial  on  FT  AM  Concurrency  Control,  November  1993 

BWQ6  Conformance  Totting  Vocabulary  (EWOS  approval  expected  Mey  1994) 

BWOS  TTCN  Style  Guide  (EWOS  approval  expected  November  1994) 

BWOS  Library  at  Teet  Specifications  (EWOS  approval  expected  November  1994) 

BWOS  fhilrtelinea  for  Managed  Object  Harmongatioo  (EWOS  approval  expected  November  1994) 

dW  Teet  Cam  Selection  Holm 

jtci  working  documents 

JTCl  New  Work  Item  Prepeeeh  for  SCSI 

JTCI  N  960  Pnpoaal  for  an  NWI  Mmagement  Information  Regitlar  and  Registration  Procedure  (in  June  1993, 

SC21  recommended  to  JTCI  that  foe  project  be  cancelled  [SC21 N7944J) 

JTCI  N  2246  Ptopoeal  for  an  NWI:  Command  Sequencer  (comment!  on  JTCI  ballot  were  maolved  by  SC21  in 

Jane  1993  and  foe  mviaod  NWI  propood  forwarded  to  JTCI  for  consideration  [SC21 N  7943]) 

JTCI  N  224*  Proposal  for  an  NWI:  Eabenremmt  of  Directory  Operational  Security  (mm menu  on  JTCI  ballot 

wen  resolved  by  SC21  in  Jane  1993  end  foe  revised  NWI  proposal  forwarded  to  JTCI  for 
consideration  [SC21  N  7933])  (revisions  to  nine  parte  of  ISO  9594  and  possibly  one  new  part; 
WDs  expected  February  1994,  CDs  November  1994,  DISe  May  1995,  and  ISe  May  1996) 

JTCI  N  2249  Proposal  for  an  NWI:  Removal  of  Session  Layer  Serial  Number  limitation  (comments  on  JTCI 

ballot  wen  maolved  by  SC21  in  June  1993  and  foe  revised  NWI  proposal  forwdad  to  JTCI  for 
consideration  (SC21  N  7985]) 

JTCI  N  22(4  Proposal  for  an  NWI:  Titans inw  to  ACSB  Coveting  ASOt  and  ASO- Associations  (comments  on 

JTCI  ballot  (JTCI  N  2507]  warn  resolved  by  SC21  by  tnviring  foe  coops  of  weak;  foe  project  has 
bean  ■*»■«■  to  SC21  program  of  wwk  (SC21 N  >076]) 

JTCI  N  2612  Ptopoeal  for  an  NWI:  Open  Syitima  Amassment  Methodology.  Angnet  1993  (failed  to  qualify  for 

JTCI  program  of  work,  as  five  P  member!  do  not  commit  to  active  participation  (JTCI  N  2773, 
December  1993D 

JTCI  N  2620  Proposal  for  an  NWI:  Conformance  Testing  of  OSI  Protocols  Over  OSI  Services  Provided  by  Non- 

O®  Protocols,  August  1993  (SC21  N  SOU.  Jaw  1993)  (foiled  to  quail*  for  JTCI  program  of  work, 
at  five  P  members  do  not  commit  to  active  pawiclpetiou  (JTCI  N  2774,  December  1993]) 

JTCI  N  2621  Proposal  for  an  NWI:  Conceptual  Scheme  Modelling  Facility,  August  1993  (9C2I  N  >060,  June 

1993]  (balloting  ended  in  November  1993)  (WD  expected  July  1995,  CD  July  1996.  DIS  July  1997, 
and  IS  My  199>) 

JTCI  N  2760  Proposal  for  «  NWL  Amendment  to  BOflBC  >473-1  Covering  BxtonaibHity  and  Quality  of 

Service,  Deoaaabar  1993  (SC6  N  8518,  Huvmsbw  1993]  (bdoting  ends  16  March  1994)  (PDAM  to 
ISQflBC  >473-1  expected  October  1993,  DAM  March  1994,  and  AM  November  1994) 

JTCI  N  2769  Proposal  for  m  NWI.  Extmsioe  to  ISOfiEC  >072  for  Protection  Quality  of  Service,  December  1993 

(SCO  N  >560,  November  1993]  (baOotiag  ends  1  April  1994) 

JTCI  N  2901  Proposal  for  m  NWL  ISOTEC  7496-n.  Archheeture  for  Multipass  Communications  (SC21 N  MM3] 

(balloting  ends  29  Match  1994)  (new  part  to  ISO  749t;  WD  expected  in  1995,  CD  in  1996,  US  in 
1997,  and  IS  fat  199S) 

JTCI  N  2902  Proposal  for  m  NWL  BuhmtnmeuU  to  LOTOS,  Deoemher  1992  (SC21  N  >022]  (balloting  ends  29 

Mach  1994)  (PDAM  to  ISO  >907  expected  Jens  1995,  DAM  June  1996,  and  AM  Jane  1997) 

JTCI  N  2903  Proposal  far  an  NWL  Directory  Scfaaaaa  Migration,  December  1992  [SC21  N  7942]  (balloting  ends 

29  March  1994)  (rtririona  to  nine  parts  of  ISO  9594;  WDs  expected  July  1994.  CDs  November 
1994,  DISs  May  1995.  md  ISe  May  1996) 

JTCI— Other 

JTCI  N  2642  Rev.  Calling  Nodes  and  Dnfl  Agenda  for  the  Writ  Meeting  of  ISQIIBC  JTC1/SC21  Joint  Woriiug  Group 

9,  Corrected  Veratan,  SC21  Secretariat,  September  1993  (to  process  the  Interpretation  of  ISOriBC 
Guide  25  for  Information  Technology  Testing  Laboratories  for  Software  and  Camaantocatioaa 
Tasting  Services  (JTCI  N  2527]  and  produce  a  revision  for  baBottng  as  a  draft  techniral  report;  held 

30  November  to  2  December  1993  in  London) 

JTCI  N  2775  Sununery  of  Voting  on  Do  cornier  JTCI  N  2621,  Proposal  for  a  New  Worts  bam:  Conceptual  S  throw 

Modelling  Facility.  December  1993 

JTCI  N  2S35  Report  Rom  ISO/IEC  JTC1/SC21  Chahman  on  Activities  Related  to  Application  Program  fcmrfaom 

(APIs)  and  ModeOiag  Fadtitiss  (MFa),  January  1994 
JTCI  N  2936  JTC1/SC21  Rapoats  on  Application  Program  Intarfarai  (APIs),  January  1994 
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SGFS  WORKING  DOCUMENTS 

SGPS  N  9S3  UK  Discussion  Paper  Relating  to  User  Requirements  Relevant  to  Opea  Systems  Assessment 

Methodology,  July  1993 

SGFSN  1003  Modification  of  SD-1,  SGFS  Procedures.  for  Adoption  of  PTSs  and  APIs,  August  1993 

SGFS  N  1043  Liaison  Statement  to  SGFS  and  EWOS/EG-OSE,  OIW,  November  1993 

SGFSN  1056  EWOS  Major  Comments  on  the  Third  Working  Draft  of  TR  10000  Part  3  (1SCVIEC  JTC1/SGFS  N 

1024)  and  Proposals  for  Change.  EWOS,  November  1993 
SGFSN  1065  US  CommeoU  on  OIW  Liaison  Statement  to  SGFS  and  EWOS/EG-OSE,  August  1993 

SGFS  N  1076  Liaison  from  AOW/EWOS/CXW  to  SGFS  on  Submission  of  AOM  2x  Taxonomy,  SOPS,  December 

1993 

SGFSN  1078  Draft  Guide  to  the  POSIX  Open  System  Environment  (P1003.Q/D16.1),  IEEE  Computer  Society, 

December  1993 

SGFS  N  1087  liaison  Statement  to  SC21/SWG-PS.  SGFS,  December  1993 

SGFS  N  1069  While  Paper  on  OSE  Profiling  Concepts,  SGFS,  December  1993  (materiel  offend  for  integration  in 

ISO/IEC  TR  10000) 

SGFS  N  1090  Liaison  Statement  to  JTC1  on  the  Subject  of  PAS  mid  APIs,  December  1993 

SGFS  N  1098  Resolutions  Adopted  by  the  SGFS  Authorized  Subgroup  Meeting  in  Amsterdam.  29  November  to  3 

December  1993,  SGFS.  December  1993 

SGFS  N  1099  Draft  Minutes  of  the  SGFS  Authorized  Subgroup  Meeting  in  Amsterdam,  29  November  to  3 

December  1993,  SGFS.  December  1993 
SCO  WORKING  DOCUMENTS 

SC6N  7951  OSI  Low®  Layer  Security  Model,  SC6/WG5, 1993 

SC6N  7952  Lower  Layer  Secwity  Guidelines,  SC6/WG5, 1993 

SC6  N  8133  Draft  Statement  of  Expected  Benefits  Regarding  Category  C  Liaison  Between  the  Internet  Society 

and  ISO/IEC  JTC1/SC6,  July  1993 

SC6  N  8419  ISO/IEC  JTC1/SC6  Liaiaon  Contribution  to  the  Internet  Society.  November  1993 

SC6  N  8420  Statement  of  Expected  Benefits  Resulting  from  Liaison  Between  ISO/IEC  JTC1/SC6  and  the  Internet 

Society,  November  1993 
SC14  WORKING  DOCUMENTS 

SC14  N  734  Secretariat’s  Report  to  ISO/IEC  JTC1  Plenary  Meeting  in  Washington.  D  C..  1-4  Febrnmy  1994, 

SC14  Secretariat,  November  1993 
SC18  WORKING  DOCUMENTS 

SC18  N  2233  User  Requirements  for  Security  in  Text  and  Office  Systems 

SC22  WORKING  DOCUMENTS 

SC22/WG1S  N  46  Rev.  Security  Interface  for  POSIX,  SC22/WG15, 1993  (spproved  new  work  item) 

SC27  WORKING  DOCUMENTS 

SC27  N  209  Non-Repudiation  Mechanisms  (Part  1:  General  Model;  Part  2:  Mechanisms  Using  Symmetric  Key 

Techniques;  and  Part  3:  Mechanisms  Using  Asymmetric  Techniques),  SC27/WG2 
SC27  N  467  Collection  and  Analysis  of  Requirements  for  Information  Technology  Security  Criteria,  SC27/WG3 

SC27  N  683  Security  Information  Objects.  SC27/WG1.  1993 

SC27  N  691  Guidelines  on  the  Use  and  Selection  of  Security  Services  and  Mechanisms  for  the  Management  of 

Trusted  Thud  Party  Services,  SC27/WG1. 1993 

SC27  N  697  Glossary  of  Information  Technology  Security  Definitions,  SC27/WG1,  1993  (SC27  Handing 

docmeot) 

SC27N718  Evaluation  Criteria  for  Information  Technology  Security,  Part  2:  Introduction  and  Model. 

SC27/WG3,  1993 

SC27  N  721  Evaluation  Criteria  for  Information  Technology  Security,  Part  3:  Functionality  of  IT  Systems, 

SC27/WG3,  1993 

SC27N734  Evaluation  Criteria  for  Information  Technology  Security,  Part  1:  Assurance  of  IT  Systems, 

SC27/WG3,  1993 

SC27  N  791  Security  Incident  Reporting;  WG1  Meeting  No.  7;  12-13  Octet**  1993  in  Paris,  SC27/WG1. 

November  1993 
SC29  WORKING  DOCUMENTS 

SC29N  363  Image  Compreation  Across  Multiple  Components  (WD  expected  November  1993,  CD  m 

November  1996,  ESS  in  July  1997,  IS  m  1998) 

SC29N  364  Lossy/Lossles*  Coding  of  Bi-level  Images  (WD  expected  November  1993,  CD  November  1996,  US 

in  July  1997,  IS  in  1998) 

SC29  N  363  Compression  of  Up  to  3-D  Images  (WD  expected  November  1993,  CD  in  November  1996,  D(S  fas 

July  1997,  in  IS  1998) 

SC29  N  366  Lots  less  Compression  of  Continuous-Tone  Still  Pictures  (WD  expected  November  1993,  CD  in 

November  1996,  D(S  in  July  1997,  IS  in  1998) 

SC29  N  367  Very-low  Bitrtte  Audio-Visual  Coding  (in  four  puts:  Systems,  Video,  Audio,  and  Conformance 

Testing;  WD  expected  in  November  1996,  CD  in  November  1997,  DIS  in  March  1998,  and  IS  in 
November  1991) 


Appendix  E 


E-41 

UNCLASSIFIED 


Standards  By  Number 


UNCLASSIFIED 


SC29N36S  Low-Bk-Rats  Audio  Coding  (WD  expected  in  Noveufoer  1995  aod  CD  in  November  1997) 

SCSI  WORKING  DOCUMENTS 

SC21  N  197  Concepts  sad  Terminology  for  tbe  Conceptual  Schema  end  the  Information  Baae,  TC97/SC5, 

March  1912 


SC21N236 

SC21N32S3 
SC21  N  3711 
SC21N3885 
SCSI  N  3906 


Asaeaament  Guidelines  for  Conceptual  Schema  Language  Proposals,  TC97/SC2  l/WGS-3, 
Aegest  19S3 

Working  Draft  for  Lower-Layer  Security  Model,  December  1988  [SC21/WG1] 

Requirements  for  Multipeer  Data  Transmission.  July  1989 
UN/EDIFACT  Information  Pack,  September  1989 

Final  Report  to  SC21  in  Florence  on  the  Reassessment  of  Project  JTC  1.21.9.1  on  Multipass  Data 
Transmission.  October  1989 


9C2I  N  4077 
SC21N408S 
SC21  N  4091 
SCSI  N  4189 
SC21N4279 
SC21N46S1 
SC21N4833 
SC21N4833 

SC21N4836 

SC21N4970 
SC21  N  5110 

SC21  N  5137 

SCSI  N  5185 
SC21N5194 
SCSI  N  5228 
SC21NS229 
SCSI  N  5394 
SC21N5580 
SCSI  N  5581 
SCSI  N  5593 

SC21N5S3S 

SC21  N  5714 

SCSI  N  5731 
3C21N5738 
SCSI  N  5817 
SCSI  N  5819 
SCSI  N  8017 
SC21N8037 
SCSI  N  8089 

SC21  N  8070 

SCSI  N  8008 
SCSI  N  8088 

SCSI  N  8110 

SC21  N  8130 

SC21N8157 
SCSI  N  8158 
SCSI  N  8159 

SC21  N  8180 
SCSI  N  8194 


Fault  Management  Wotting  Document.  SC21/W04.  December  1989 

Accounting  Management  Working  Document,  Third  Version,  SC21/WG4,  November  1989 

OSI  Security  Management  Working  Document,  November  1989 

Comments  on  the  Integration  of  X-Windowi  into  the  OSI  Environment,  December  1989 

CCR  Conformance  Test  Suite,  January  1990  (new  work  item)  (CD  text  expected  June  1995) 

User  Requirements  for  Multi-Party  Communications  (MFC),  Canada,  May  1990 
Report  to  J1C1  Cram  SC27  on  Security  Techniques.  SC27  Secretariat.  May  1990  [SC27  N  94] 
Report  of  the  Hist  Plenary  Meeting  of  SC27  at  Stockholm,  24-26  April  1990.  SC27  Secretariat. 
May  1990  [SC27  N  92] 

Resolutions  Taken  at  tbe  First  Plenary  Meeting  of  SC27  at  Stockholm,  24-28  April  1990, 
May  1990  [SC27  N  94] 

Systems  Management  Tutorial  -  Annex  A:  Access  Control.  May  1990 

Call  to  National  Bodies  and  Liaiaon  Organisations  for  Contributions  on  Technical  Structure  of 
Quality  of  Service  (QOS)  Architecture,  May  1990 

Data  Management  Export/Import  for  SQL  and  RDS,  SC21/WQ3,  October  1990  (new  work  item;  CD 
text  expected  December  1992) 

FTAM  Constraint  Set  and  Docummt  Types  for  COM,  SC21/W05.  June  1990 
Resolutions  of  the  Fourth  Plenmy  Meeting  of  SC21,  Jane  199Q,  Seoul.  SC21.  June  1990 
Report  of  foe  ISQflEC  JTC1/SC21  Plenery  Meeting.  June  1990.  Seoul.  Korea.  July  1990 
Report  of  foe  JTC1/SC21  Ptonary  Meeting,  June  1990,  Seoul.  RepuMic  of  Keren 
Collections  of  Definitions  of  OSI  Vocabulary,  June  1991 

New  Area  of  Work  for  SC27/WG1  on  IT  Secmity  Information  Objects.  January  1991 

New  Area  of  Work  for  SC27/WQ1  on  IT  Security  Terminology.  Jsunery  1991 

The  Role  of  the  Extended  Application  Layer  Structure  in  foe  Standardization  of  RFC.  ECMA,  Jaunwy 

1991 

Report  of  the  Special  Working  Group  on  a  Conceptual  Model  for  Electronic  Data  Interchange 
Standards  and  Services  (SWG-EDl),  January  1991 

Resolutions  of  the  ISO/IEC  JTC1  Advisory  Group  Meeting.  Washington.  DC.  19-21  February 
1991.  March  1991 

Progression  of  the  Upper  Layers  Security  Standards.  Canada,  April  1991 
Discussion  Paper  on  Conformance  and  Registration.  BSL  March  1991 
Binding  Concepts  Within  RPC,  ECMA.  March  1991 
Modelling  Rationale  for  OSI  RPC  ECMA,  March  1991 

r*— - e*.  on  of  Application  FTogrmnmatic  (sic)  Intorfoess.  WG4,  May  1991 

Need  for  Security  Services  with  OS  Management,  SG4.  July  1991 

Proposed  New  WG6  Question  Q6/2  on  foe  Relationship  Between  the  OSI  Upper  Layer  Archhectme 
and  OOP.  July  1991 

Working  Draft  Answer  to  the  Proposed  WQ6  Question  on  the  Architectural  Relationship  Between 
OSI  and  OOP.  June  1991 

Reeotatkm  of  Ballot  Comments  oo  the  NP  on  ODP  Trader.  SC21/WG7.  May  1991 

Proposal  for  a  WG7  Question  on  the  Suitability  of  the  Formal  Description  Technique  Z  for  Use  in 

OOP.  May  1991 

Session  Layer  Extension  to  Support  Re-Use  of  Transport  Connections.  WG6,  JTC1  N  1438. 
July  1991  (voting  ended  21  October  1991)  (new  work  hem) 

Working  Draft  for  ASN.l  Encoding  Raisa  to  Provide  Upper  Layer  Security  aad  Compression.  WQ6, 
June  1991 

Answer  to  CCITT  SG  VII Q  23  on  OSI  Reforaaoe  Model  Regarding  ISDN,  Msy  1991 

Final  Answer  to  Ql/62  (Quality  of  Service  Architectural  Issues),  WOl,  May  1991 

rtemewosk  on  Quafity  of  Service,  WG1,  May  1991  (new  project  proposal  for  a  TR)  (PDTR  projected 

for  May  1993,  DIR  May  1994,  TR  May  1995) 

Catalogue  of  PICS  Proforma  Notations,  WG1.  July  1991 

Final  natuirau  In  IJlfffT  1  Miring  - -  »-  foe  text  of  OSIMaag — - 

WOl,  May  1991 
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SCSI  N  <197  WOl  Position  oa  the  Reactivation  of  Project  1.21.9.1  (Multi-Peer  Data  Trmmrlirioa).  WG1. 

July  1991  (national  body  rnmmantt  requested  by  31  Much  1992) 

SC21  N  6198  Afinvad  oatfaaOSI  Basic  Reference  Modal  (SC21  SD-9],  My  1991 

SC21N6224  Fwpoesd  BDjFACT/FTAM  Document  Type,  WP3.  July  1991 

SC21  N  <223  Response  to  Liaison  tom  JTC1/SC24/WG3  about  COM  Docameat  Types,  My  1991 

SC21N6227  Virtual  Terminal  Support  of  ODA.  WG3,  My  1991 

SCSI  N  6249  Resototiooe  of  the  SC21/WG3  Meeting.  Aries  (May  1991),  My  1991 

SCSI  N  6231  Proposed  New  Question  oa  the  IRDS  Defioitioo  Level  Coeteat  Standard  for  Sammtic  Uatficattoa 

Meta  Model  (SUMM),  My  1991 

SCSI  N  6232  Revision  of  die  DtDS  Framework,  WG3,  My  1991  (new  west  ham) 

SC21  N  <233  Proposed  New  Question  on  the  Approach  to  Remote  DtDS  Access,  My  1991 

SC21  N  <237  Recommendation  oa  NWI  for  Stoied  ML  Procedures.  My  1991 

SC21  N  6273  Rasolatioas  of  the  Seventh  Pleaary  Meeting  of  ISOriEC  JTC1/SC21,  4-5  Jane  1991,  Aries, 

France,  June  1991 

SC21  N  <306  (Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management  -]  Performance 

Management  Working  Document  •  Seventh  Draft.  My  1991 

SC21  N  <370  Register  of  Object  Identifier  Components  Allocated  to  Areas  of  Joint  ISCVCCITT  Work. 

August  1991 

SC21  N  6403  Proposal  for  a  New  Work  Item:  Generic  Operating  System  Interface,  September  1991 

SC21  N  6478  Target  Dales  for  Completion  of  SC22  Projects,  November  1991 

SC21N6S27  Resolutions  of  the  ISGffEC  JTC1  Plenary  Meeting,  October  2-4, 1991,  Madrid,  JTC1  Secretariat 

SC21N6330  Report  of  the  JTC1  Plenary  Ad  Hoc  Group  on  EDI,  October  1991 

SC21  N  <386  Meeting  Report  -  Collaborative  CCITT  Q19/VH  and  SC21/WG6  Meeting  oa  Upper  Layer*  Security, 

December  1991 

SC21  N  6604  Summary  of  Voting  on  Document  JTC  1  N  1434,  Proposal  for  a  New  Work  Item  on  Enhancements  to 

Light  Weight  Encoding  Rules,  JTC1  Secretariat,  April  1992 
SC21  N  6606  Collection  of  Liaison  Statements  from  SC27  to  SC21,  May  1992 

SC21  N  <614  SC21  Remmmanilail  Action  to  Address  Problems  of  Data  Modelling  Standards  Coordination, 

Deesmbar  1991 

SC21  N  6613  The  Procoasing  of  Stand  ndr  in  SC21,  SC21  Special  Meeting  on  Structure  and  Organisation.  ANSL 

10-13  Dacamber  1991.  December  1991 

-  SC21  N  6619  Raaolutioaa  of  the  SC21  Special  Meeting  on  Structure  and  Organization.  ANSL  10-13  December 

1991.  Dacamber  1991 

SC21N6638  lasaas  for  National  Body  and  Liaison  Organization  Comment  on  RPC,  June  1992 

SC21  N  <639  Proposed  Liaison  Statement  to  SC21/WG4  Regarding  General  and  Dependent  Conformance. 

January  1992 

SC21  N  <640  Health  Warning  Regarding  General  and  Dependent  Conformance,  JTCl-CdTT  Interim  Meeting  on 

Conformance.  November  1991.  January  1992 

SC21  N  6633  Various  Contributions  to  the  ISOflBC  JTC1/SC21  Special  Group  Meeting  on  Conceptual  Schema 

and  Coaaaaon  Data  Modelling  Facilities.  9-13  March  1992.  Renesse.  The  Netherlands 
SC21N6636  Liaiaoe  Stotimant  to  SC21/WG6  on  Compatibility  of  ROS  and  RPC 

SC21  N  6664  liaison  Statsmsnt  to  SC22/WG13  on  Software  Management.  January  1992 

SC21  N  6667  Contributions  from  ISOAEC  JTC1/SC18  Rag  anting  the  Progression  of  Work  on  Multimedia  and 

Hyparamiia  Modal/Brmtework 

SC21  N  6693  Liaison  Statement  from  SC21/WG1  Security  Ad  Hoc  Group  to  SC21/WGS  TP  on  Preliminary 

Security  ModeL  Jwuarv  1992 

SC21N67U  SC21  SIM.  SC21  Strategic  Plan.  January  1992 

SC21N6713  CCITT  Cucular  No.  118  Regarding  the  Catalogue  of  COTT  Racoamaandatiour.  January  1992 

SC21N6714  List  of  Contact  Points  of  SJGs/EGs  of  Regional  Workshops.  January  1992 

SC21  N  6715  Lsttsr  from  OTWOCIT 1  RsganBag  Piepatetion  of  CCITT-ISOflBC  Conunon  Text.  Jammy  1992 

SC21  N  6719  Recommendations  of  the  COTT  and  ISO  Collaborative  Interim  Meeting  Covering  ROSE 

Enhancement*,  April  1992 

SC21N6722  banes  Concerning  Mapping  of  ROSE  APDUs  onto  A-UNTT-DATA.  January  1992 

SC21  N  <723  Enhancement  to  ROSE,  Part  3:  Concepts,  Modal  and  Notation.  Worktog  Draft,  Jnsuary  1992  OS 

expected  November  1993) 

SC21  N  <724  Enhancement  to  ROSE,  Part  1:  Service  DefMtiou.  Working  Draft,  January  1992  (IS  expected 

November  1993) 

SC21  N  <723  Bnbmnamsnt  to  ROSE.  Protocol  Definition,  Working  Draft.  Jnmary  1992  (IS  expected  November 

1993) 

SC21  N  <728  Summary  of  Planned  Contribution*  to  the  Reaasaa  Special  Meeting  on  Conceptual  Schama 

Facilities  and  Common  Data  Modelling  Faculties,  April  1992 
SC21  N  6737  Object  Oriented  Task  Group  Final  Report,  February  1992 

SC21  N  <749  Proposal  for  a  New  Work  Item  on  Information  Technology  •  Text  CnmmunlraHou  -  Coordinated 

Time  Smvloa  in  an  09  Eavtomneat,  February  1992 
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SC21  N  6755 
SC21  N  6756 
SC21  N  6759 
SC21  N  6760 
SC21  N  6765 

SC21N6776 

SC21  N  6777 
SC21  N  6778 
SC21  N  6779 
SC21N6793 

SCSI  N  6794 
SCSI  N  6796 
SC21N6797 
SC21N679S 
SCSI  N  6799 
SCSI  N  6001 

SCSI  N  6002 
SCSI  N  6*07 
SC21N6S0S 
SCSI  N  6109 
SC21  N  6810 
SC21  N  6811 
SC21  N  6812 

SC21  N  6813 
SC21  N  6814 

SCSI  N  6819 

SC21N6820 

SC21N6821 

SC21N6822 

SC21N6842 

SC21  N  6843 
SC21  N  6844 
SC21N6870 

SC21  N  6872 

SC21  N  6875 

SC21N6877 
SCSI  N  6878 

SC21N6879 

SC21  N  6880 

SCSI  N  6881 

SC21  N  6883 
SC21N6S91 

SCSI  N  6892 
3C21  N  6893 
SC21N6S94 


Contribution  an  Key  Management,  February  1992 
HVCCR  One-Phaee  Cosnmtanent,  February  1992 

Recommendation  oo  SQL2  Progression  (ISQ1EC  CSS  9075),  February  1992 
Mlnotea  of  the  SQL2  Editing  Meeting,  Kawagoe,  February  1992 

Guide  to  Open  Systems  Security  Collaborative  SC21/CCITT  Security  Ad  Hoc  Group  Meeting, 
November  1991,  February  1992 

Framework  A  Taxonomy  of  International  Standardized  Profiles  -  Directory  of  ISPs  and  Profiles 
Contained  Therein.  March  1992 

Letter  from  ISO  Regarding  the  Disbandment  of  GOST,  March  1992 

COTT  Interim  Meeting  Schedule  -  Late  1992/Early  1993,  March  1992 

Statement  Regarding  Participation  at  CCTTT  Study  Group  Meetings,  March  1992 

Proposed  Mechanism  for  Soliciting  National  Body  Input  on  Multipeer/Multicast  Application 

Requirements,  Marefa  1992 

Preliminary  Raquhemanls  for  a  Multi-peer  Data  Communication  Architecture,  March  1992 

US  Response  oo  Application  Context  Negotiation.  March  1992 

Coaaments  oo  SC21  N  6068,  Modelling  Recovery  in  tbe  Application  Layer,  March  1992 

US  Request  for  Extousiom  to  ACSE,  March  1992 

Contribution  oo  Upper  Layer  Management,  March  1992 

Conuueats  on  SC21  Recommended  Action  to  Address  Problems  of  Data  Modelling  Standards 
Coordination,  March  1992 

Problems  urith  Certifying  FT AM  Implementation  as  Conformant,  March  1992 
Protocol  Version  Numbers,  March  1992 

Organization  of  Work  on  OSI  and  ODP  Architecture,  UK  National  Body.  March  1992 
Request  for  Reassessment  of  the  Terminal  Management  Project,  Match  1992 
UK  Position  on  General  and  Dependent  Conformance,  March  1992 
FTAM  Aspects  of  Security,  March  1992 

Request  to  Apply  tbe  Procedures  for  the  Reactivation  of  the  Multi-Peer  Data  Transmission  Project 
(MPDT),  March  1992 

Draft  Addendum  for  MuHi-Feer  Data  Transudwinn  Project  (MPDT),  March  1992 

Liaison  ftatammit  to  SC21  an  Lower  Layer  Multicast  Work  SC6  Enhanced  Transport  Mechanisms 

Matting,  March  1992 

Rspart  of  the  ISOfiEC-CCITT  Joint  OSI  Conformance  Group  Interim  Meeting  Held  in  Durham.  North 
Carolina.  4-8  November  1991,  March  1992 

Liaison  Statement  for  SC22/WGU,  Binding  Techniques,  to  SC21/WG6  RPC  Rapporteur  Group. 
March  1992 

letcnurtmullratinn  of  the  Directory,  January  1992 

UK  Response  to  N  6011,  Call  for  Contributions  on  Directory  Enhancements,  January  1992 
US  Concerns  Regarding  the  Ballot  Responses  on  the  Authentication  Service  NP  and  Enhancements 
to  Directory  Authentication  NP,  April  1992 
Contribution  on  Non-Rapndiatioa  Framework,  April  1992 
Contribution  on  Security  Pranwwotki  Overview,  April  1992 

Proposal  for  a  New  Work  Item  on  Mapping  of  the  OSI  System  Management  -  Object  Management 
Function  onto  Maas  age  Oriented  Text  Interchange  System  (MOTIS),  April  1992 
Liaison  Statement  to  COTT  Q20/VD  and  SC21/WG4  from  SC  18  on  MHS  Use  of  Directory. 
April  1992 

Liaison  Statement  to  SC21  from  SC18  on  Revised  Draft  Guide  to  Open  Systems  Security, 
April  1992 

Liaison  Stntameut  to  SC21  from  SC18  on  Security  Framework  SC18,  April  1992 

Liaiaou  Statamtnt  to  COTT  Q19/VB  and  SC21/WG6  from  SC  18  on  Use  of  the  Security  Exchange 

ASE,  April  1992 

Liaiaoa  Statement  to  SC21/WG6  FTAM  from  SC18  oo  MHS  File  Transfer  Body  Part  Type, 
April  1992 

Liaison  Statement  to  COTT  Q19/VD  and  SC21/WG6  from  SC18  on  Reliable  Transfer  Service 
Element  (RTSE),  April  1992 

Liaiaoa  Statement  to  SC21/WG1  from  SC1S  on  Conformance  in  Response  to  SC18  N  3291, 
April  1992 

Report  of  the  Secretariat  to  the  SC21  Meeting  to  Ottawa,  2-3  Jane  1992,  April  1992 

Liaison  Statement  to  SC  18  md  SC21  oo  tbe  States  of  COTT  X.400/X.500  PICS  Proforma 

Racnmmandattom  and  Future  Collaborative  Work.  May  1992 

Liaison  Statement  to  SC21/WG4  on  Atomic  Transaction  Interfaces,  May  1992 

Liaison  Statement  to  SC21  on  Approval  of  Management  Framework,  May  1992 

Liaiaoa  Statement  to  Joint  COTT/ISO  9S96-2/X.712  Editing  Meeting,  29  May  1992,  Ottawa. 

May  1992 
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SC21N6896 

SC21  N  6897 
SC21  N  6902 
SC21N69Q3 

SC21  N  6904 

SC21  N  6905 
SC21  N  6906 
SC21  N  6907 

SC21  N  6914 

SC21  N  6915 

SC21  N  6916 

SC21  N  6929 


SC21  N  6931 
SC21  N  6943 
SC21  N  6943  Rev 

SC21  N  6945 

SC21  N6948 

SC21N69S1 

SC21N69S2 

SC21  N69S5 

SC21  N  6956 
SC21  N  6957 
SC21  N  6961 
SC21  N  6966 

SC21  N  6967 
SC21  N  6968 
SC21N6969 

SC21  N6970 

SC21N6971 
SC21  N  6972 
SC21N6974 

SC21  N  6975 
SC21  N  6983 
SC21  N  6984 

SC21  N  69S3 
SCSI  N  6992 

SC21  N  6993 

SC21  N  6994 

SC21  N  6995 

SCSI  N  6996 

SCSI  N  6997 
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Liaiaoo  Statement  to  Joint  COTT/ISO  10164-13/X.738  Editing  Meeting,  29  May  to  3  Jane  1992, 
Ottawa,  May  1992 

Liaison  Statement  to  SC6  and  SC21  on  Consumer  Network,  May  1992 

Liaison  Statement  to  SC21  on  Revision  of  the  OSI  Reference  Model,  May  1992 

Request  for  the  Work  on  Procedures  for  the  Operation  of  Registration  Authorities:  Application 

Processes  and  Application  Entities  to  Become  Collaborative,  May  1992 

Liaison  Statement  to  SC21  on  Mapping  of  ROSE  APDUs  onto  the  A- UNIT-DATA  Service, 
May  1992 

Liaison  Statement  to  SC21/WG6:  Report  on  Q26/VH  Meeting,  April  1992,  May  1992 
Liaison  Statement  to  SC21  on  Efficiency  of  OSI  Protocols,  May  1992 

Liaison  Statement  to  SC 21  Concerning  Collaborative  Work  on  ODP,  Security,  ASN.l,  ROSE,  and 
RTSE,  May  1992 

Liaison  Statement  to  SC21:  Request  for  Review  &  Comment  on  Profile  Choices  for  Subclasses  of 
the  EFIVLOG  Managed  Object  Classes  Using  Allomorphism  A  Best  Efforts  Management,  May  1992 
Liaison  Statement  to  SC  21  Regarding  Profiles  for  Systems  Management  Functions  (10164-1  to  -6) 
A  Definition  of  Management  Information  (10165-2),  May  1992 

Liaison  Statement  to  SC21/WG6  Concerning  the  Use  of  ASN.l  in  the  Image  Processing  and 
Interchange  Image  Interchange  Facility  (IPI-IIF)  Standard,  May  1992 

JTCl  National  Body  Comments  Received  on  JTC1  N  1756,  Request  for  Review  and  Comment  on  the 
SC 21  Recommended  Action  to  Address  Problems  of  Data  Modelling  Standards  Coordination, 
May  1992 

Working  Draft  for  SQL-3,  Interim  Database  Languages  Meeting,  Japan,  May  1992 
Requirements  and  Recommendations  Regarding  Protocol  Version  Numbers,  May  1992 
Requirements  and  Proposed  Recommendations  of  the  Protocol  Version  Numbers  Pre-Meeting  (and 
the  Initial  ITTF  Response),  August  1992,  Revised 

Recommendations  and  Proposed  Work  on  Conceptual  Schema  and  Data  Modelling  Facilities, 
May  1992 

Responses  to  the  Proposed  Mechanism  for  Soliciting  National  Body  Input  on  Multipeer/Multicast 
Application  Requirements,  May  1992 

Reference  Material  on  Conceptual  Schema  and  Common  Data  Modelling  Facilities,  May  1992 
Report  of  the  9-13  March  1992  Renesse  Meeting  of  the  SC21  Special  Group  on  Conceptual  Schema 
and  Common  Data  Modelling  Facilities,  May  1992 

Stocktaking  of  Standards  and  Standards  Projects  which  Make  Use  of  a  Data  Modelling  Facility  or  of 

a  Conceptual  Schema,  May  1992 

Stains  Report  on  CQ'iT  SG  Activities,  May  1992 

Project  Dependencies,  June  1992 

SC21/WG1  Decision  on  MPDT  Reactivation,  May  1992 

Incorporation  of  Versions  and  Extensibility  Technical  Material  into  Existing  Standards  and  Other 
Documents,  May  1992 


Modelling  Recovery  in  the  Application  Layer,  May  1992 

Request  for  Comment  on  Issues  Concerning  Upper  Layer  Management,  May  1992 

Comments  on  SC21  N  6943,  Recommendations  and  Requirements  on  Protocol  Version  Numbers, 

May  1992 

Call  for  Comments  on  the  Progression  of  the  ALS  Extension  to  Cover  Connectionless  Mode  of 
May  1992 


Application  of  XALS  Concepts  to  Specification  of  Mappings,  May  1992 
Draft  Answer  to  Q6/2  -  Relationship  Between  the  OSI  Upper  Layer  Architecture  and  ODP,  May  1992 
Liaison  Statement  to  SC6  Concerning  a  Request  for  Incorporation  of  New  Protocol  Information 
Attributes  in  ISCyiEC  9594-6/DAM  1.  June  1992 

Need  for  Procedures  to  Coordinate  the  Definition  end  Extension  of  Directory  Objects.  May  1992 
Liaison  Statement  to  SC24  Concerning  the  Use  of  ASN.l  in  tbs  ttVOF  Standards.  May  1992 
Class  of  Mappings  from  a  Single  ASN.l  Type  to  an  FT  AM  Document  type.  July  1992  (target  dates 
ate  WD  in  July  1993,  CD  in  July  1994,  DIS  in  July  1995,  and  IS  in  July  1996) 

Request  for  Comments  on  Compression  in  Presentation  Layer.  June  1992 

Generic  Upper  Layer  Security  (GULS),  Part  1:  Overview,  Models  end  Notation,  Third  Working 
Draft,  May  1992  (SC21/WG6) 


Generic  Upper  Layer  Security  (GULS),  Part  2:  SESE  Service  Definition,  Third  Working  Draft, 
May  1992  (SC21/WG6) 

Generic  Upper  Layer  Security  (GULS),  Part  3:  SESE  Protocol  Specification  Third  Working  Draft, 
May  1992  (SC21/WG6) 

Generic  Upper  Layer  Security  (GULS),  Pert  4:  Protecting  Transfer  Syntax  Specification,  Third 
Working  Draft,  May  1992  (SC21/WQ6) 

Liaison  Statement  to  SC6  on  Common  Aspects  of  OSI  Upper/Lower  Layer  Security  Standards, 
May  1992 

Liateon  Statement  to  ECMA  on  Security  in  the  Upper  Layer*.  May  1992 
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SC21  N  6998  Authentication  and  Related  Security  Services  for  Distributed  Applications,  July  1992  [target  dates: 

WD  (5/93),  CD  (5/94),  DIS  (5/95),  and  IS  (9/96)] 

SC21  N  7011  liaison  Statement  to  SC18  on  Compatibility  of  ROSE  and  RPC  SC21/WG6,  May  1992 

SC21  N  7013  Enhancement  to  ROSE  Concepts,  Model  and  Notation,  ROSE  Service  Definition  and  Protocol 

Specification,  July  1992  [addendum  or  addenda  to  ISO  9072-1,  ISO  9072-2,  and  ISO  9072-3; 
target  dates  are  WD#1  (5/92),  WD#2  (11/92).  CD  (8/93),  NS  (2/94),  and  IS  (2/95)] 

SC21  N  7014  ACSE  Enhancements  Covering  ASOs  and  ASO- association* 

SC21  N  7016  Presentation  Connection-Oriented  Abstract  Test  Suite  (ATS),  Specific  Partial  ATS 

SC21  N  7018  Use  of  Systems  Management  for  Administration  of  the  Directory  [JTC1  N  1440R] 

SC21  N  7020  Enhancement  of  Directory  Operational  Security,  July  1992  [would  result  in  an  addenda  to  ISO  9594- 

1  through  ISO  9594-9  and  possibly  one  new  part;  target  dates  are:  WD  (1 1/94),  CD  (10/95),  DAM 
(10/96),  and  IS  (10/97)] 

SC21  N  7021  Registration  of  Question  Q4/4  on  Directory  Schema  Migration,  Including  Disposition  of 

Comments,  May  1992 

SC21  N  7024  Request  for  Contributions  on  Use  of  Systems  Management  for  Administration  of  the  Directory, 

May  1992 

SC21  N  7025  Request  for  Contributions  on  Movement  of  Directory  Information  by  Means  Other  Than  Directory 

Protocols,  May  1992 

SC21  N  7026  Request  for  Comments  on  the  Need  for  an  Extension  to  the  Directory  Standard  to  Support  Extended 

Relationships  Among  Directory  Entries,  May  1992 
SC21N7028  Status  of  Directory  Defects,  May  1992 

SC21N7042  The  RM-ODP  and  Standardization  of  APIs,  May  1992 

SC21  N  7047  ODP  Trader,  July  1992,  WG7,  WD  status  (CD  expected  November  1993;  NS  November  1994;  IS 

November  1995) 

SC21  N  7051  Proposed  Draft  Answer  to  Question  Q7/1  on  the  Suitability  of  the  Formal  Description  Z  for  Use  in 

ODP,  May  1992 

SC21  N  7052  Editing  Instructions  for  a  Technical  Report  on  Use  of  FDTs  (Specification  Technique)  in  ODP, 

May  1992,  WG7,  WD  status  (PDTR  expected  July  1994) 

SC21N7057  List  of  Open  and  Resolved  Issues,  SC21/WG7,  May  1992 

SC21  N  7062  Liaison  Statement  to  SC6  on  Multipeer  Data  Transmission.  May  1992 

SC21  N  7063  liaison  Statement  to  CC3TT  SG  VII  on  Multipeer  Data  Transmission,  May  1992 

SC21  N  7066  Liaison  Statement  to  SC6  Concerning  Quality  of  Service  (QOS).  ISO/IEC  JTC1/SC21  Meeting, 

Ottawa,  June  1992,  July  1992 

SC21  N  7067  Results  of  the  SC21/WG1  Meeting  on  Quality  of  Service  (QOS)  Framework.  May  1992  (CD  expected 

June  1993;  DIS  June  1994;  IS  June  1995) 

SC21  N  7069  Draft  Answer  to  Ql/49.9  on  Long-term  Solution  to  General  and  Dependent  Conformance,  ISO/IEC 

JTC1/SC21/WG1  Meeting.  Ottawa,  May  1992,  July  1992 

SC21  N  7073  Proposed  New  Sub-Question  Ql/49.9  on  Long-term  Solution  to  General  and  Dependent 

Conformance,  ISO/IEC  JTC1/SC21/WG1  Meeting.  Ottawa,  in  May  1992.  July  1992 
SC21  N  7074  liaison  Statement  to  JTCl/SGFS  on  Conformance  Testing,  May  1992 

SC21  N  7075  Liaison  Statement  to  SC 6  on  ICS  Proforma,  May  1992 

SC21  N  7076  liaison  Statement  to  SC  18  on  Conformance  Testing,  May  1992 

SC21  N  7078  Draft  Answer  to  Ql/49.8  -  Conformance  and  Registration,  May  1992 

SC21  N  7079  Working  Draft  Answer  to  Ql/63.2  •  Testability  of  Managed  Objects,  May  1992 

SC21  N  7080  liaison  Statements  to  EWOS  on  Conformance  Testing,  May  1992 

SC21  N  7086  liaison  Statement  to  SC18  on  Security,  May  1992 

SC21  N  7087  liaison  Statement  to  SC27  on  Security,  May  1992 

SC21  N  7088  Proposed  New  Question  Ql/66  on  ODP  Conformance  Testing  Methodology,  May  1992 

SC21  N  7089  Statement  on  Scope  and  Usability  of  the  Open  Systems  Security  framework.  May  1992 

SC21  N  7090  Proposed  New  Question  Ql/65  on  User  Requirements  for  OSI  Systems  Supporting  Tune  Critical 

Communications,  May  1992 

SC21  N  7091  liaison  Statements  to  SC  18  on  Quality  of  Service,  May  1992 

SC21  N  7092  Proposed  New  Question  Ql/67  on  Generalization  of  ASO  Concepts,  May  1992 

SC21  N  7093  Proposed  New  Question  Ql/68  on  the  Definition  of  the  Term  Application-Process-Title  in  the  OSI 

Reference  Model  May  1992 

SC21  N  7094  Draft  Answer  to  Ql/68  -  Definition  of  die  Term  Applicstion-Process-Title  in  the  OSI  Reference 

Model  May  1992 

SC21N7096  Draft  Answer  to  Ql/48.6  -  G-LOTOS,  May  1992 

SC21  N  7098  Proposed  New  Question  Ql/69  on  Conformance  Assessments  for  OSI  Security,  May  1992 

SC21  N  7099  Resolutions  Approved  by  SC21/WG1  at  Its  Ottawa  Meeting,  20-28  May  1992,  May  1992 

SC21  N  7101  List  of  Late  Input  Documents  and  Output  Documents  erf  the  SC21/WG1  Ottawa  Meeting,  May  1992 

SC21  N  7102  Extensions  to  ISO/IEC  9594-8  (Certificate  Definitions) 

SC21  N  7109  Reply  and  Disposition  of  Comments  on  NP  on  Development  of  Enhanced  Functionality  for  CMIS/P 

(JTC1  N  1667),  ISO/IEC  JTC1/SC21/WG4  Meeting,  Ottawa,  May  1992,  August  1992 
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SC21  N  7106 

SC21  N  7107 

SC21  N  7109 
SC21  N  7116 
SC21  N  7117 
SC21  N  7118 

SC21  N  7119 
SC21  N  7122 

SC21  N  7126 
SC21  N  7129 
SC21  N  7131 

SC21  N  7132 
SC21  N  7133 
SC21  N  7134 
SC21  N  7135 
SC21  N  7140 

SC21  N  7143 

SC21  N  7144 

SC21  N  7145 

SC21  N  7146 
SC21  N  7147 
SC21  N  7148 
SC21  N  7149 
SC21  N  7156 

SC21  N  7160 
SC21  N  7162 
SC21  N  7165 
SC21  N  7166 
SC21  N  7167 
SC21  N  7168 
SC21  N  7171 

SC21  N  7172 
SC21  N  7173 
SC21  N  7175 

SC21  N  7177 

SC21  N  7178 

SC21  N  7179 
SC21  N  7180 
SC21  N  7181 
SC21  N  7182 
SC21  N  7183 
SC21  N  7184 
SC21  N  7185 
SC21  N  7186 
SC21  N  7191 
9C21  N  7195 
SC21  N  7196 
SC21  N  7197 


A|md  Requirements  for  Enhinoed  Functionality  for  SM  Communications  (JTC1  N  1439), 
May  1992 

Disposition  of  Ballot  Comments  on  JTC1  N  1439,  Proposal  for  a  NP  on  Fnh  attend  Event  Handling 

*  Log  Control  (JTL!  N  1439),  May  1992 

Pnm imivt  Sequencer  for  Systems  Management,  July  1992 

Working  Document  on  Complex  Attribute  Types,  July  1992 

Request  for  National  Body  Input  on  Principles  of  Conformance  for  Managing  Systems,  July  1992 
Management  Domains  Architecture,  WG4,  July  1992  (part  of  the  Extended  Systems  Management 
Architecture) 

Management  Domain  Management  Function,  WG4,  June  1992 

Working  Draft  on  Application  Context  for  Systems  Management  with  TP  (CD  expected 
December  1992;  MS  February  1994;  IS  February  1995) 

General  Relationship  Model-Third  Working  Draft,  WG4,  May  1992 

Request  for  National  Body  Contributions  to  Progress  Work  on  Distributed  Management,  May  1992 

Request  for  National  Body  Input  Regarding  Definition  of  Common  Terms  and  Use  of  Formal 

Description  Techniques  in  SMI  Standards,  May  1992 

Request  for  National  Body  Comment  on  NWI  for  Library /Catalogue,  July  1992 

Coherence  of  Extended  Management  Architecture,  May  1992 

Preliminary  Document  on  Multiple  Input  Metric  Object,  May  1992 

Call  for  Contributions  on  Priority  Mechanisms  in  Systems  Management,  May  1992 

Reply  to  Liaison  Statement  for  CCTTT  SG  VII  Regarding  the  Comments  on  Notations!  Tools  in 

SC21  N  6568,  July  1992 

Comments  on  Document  SC21  N  6897  from  CCTTT  Q9/V1I  on  Customer  Network  Management, 
May  1992 

Liaison  Statement  to  SC18  Concerning  Mapping  of  Systems  Management  Object  Management 
Function  onto  MOTTS,  May  1992 

Liaison  Statement  to  SC21/WG1.  SC21/WG6  (8),  SC6  and  SC27  on  Security  Requirements  for 
Systems  Management,  May  1992 

Liaison  Statement  to  SC22/WG15  on  Software  Management,  May  1992 

Liaison  Statement  to  CCTTT  Q23/IV  on  Software  MO,  May  1992 

Response  to  the  SC6  liaison  Statement  on  Event  Definition,  May  1992 

Liaison  Statement  to  SC18  Regarding  the  Status  of  the  Security  Exchange  Work,  May  1992 

Proposed  NP  for  Transaction  Processing  Abstract  Test  Suites,  July  1992  [part  rtf  the  TP 

Conformance  Testing  Standard;  target  dates  are  WD  (10/93),  CD  (6/94),  IMS  (6/95),  and  IS  (6/96)) 

FTAM  Security  Issues,  29  May  1992 

Status  of  Project  JTC1.21. 12.08.02,  FTAM  Virtual  Filestore  Service  Enhancements,  June  1992 
TP  Commitment  Optimisation  Issues  and  Resolutions.  May  1992 

Requirements  and  Issues  for  toe  Separation  of  Data  and  Commitment  Flows  in  OSI  TP,  May  1992 
Request  for  Contributions  on  OSI  TP  Subtransactions,  May  1992 

Request  for  Comments  on  Issues  Concerning  TP  Association  Pool  Management,  May  1992 
Revised  TV  Test  Suite  Structure  and  Test  Purposes,  Working  Draft,  WG5,  May  1992  (CD  expected 
June  1993;  DIS  June  1994;  IS  June  1995) 

’  General  Principles  for  toe  Development  of  TP  Test  Cases,  May  1992 
Open  Issues  and  Questions  for  the  Development  of  TP  Test  Cases.  May  1992 
Liaison  Statement  to  SC6  on  Requirement  for  Non-Blocking  Transport  Expedited  Service, 
May  1992 

Propoeed  New  Work  Item  for  Remote  Database  Access  (RDA),  Part  3:  IRDS  Specialization,  Ottawa, 
May  1992 

Proposed  NP  for  Guidelines  for  the  Design  of  IRDS  Content  Modules,  July  1992  (technical  report; 
target  dates  are  WD  (6/93),  CD  (6/94),  IMS  (6/95),  and  IS  (6/96)] 

SQL  Multimedia  sod  Application  Packages  (SQL/MM),  NWI  Proposal.  December  1992 

Propoeed  Draft  Answer  to  Question  Q3/001  -  Object  Database,  May  1992 

Propoeed  Draft  Answer  to  Question  Q3/009  •  Remote  IRDS  Access,  May  1992 

Liaisoo  Statement  to  ECMA  TC33  on  IRDS/PCTE,  May  1992 

Liaison  Statement  to  EWOS/EG  DBE  on  Profiling  SQL/RD  A,  May  1992 

Liaison  Statement  to  JTC1/WG3  on  EDI  May  1992 

Liaison  Statement  to  JTC1/SC14  on  Date  Elements,  May  1992 

Liaison  Statement  to  SC18  on  Full-Text  Manipulation,  May  1992 

Liaison  Statement  to  ISO  TC184/SC5  on  Reference  Model  and  IRDS  for  Automation,  May  1992 
SC21  Pbritioo  on  SC21  N  6484  Guide  for  CCTIT  md  JTC1  Collaboration.  Juna  1992 
SC21  SD-  8,  SC21  Schedule  of  Meetings  SC21  Plenary  Meeting.  June  1992,  Ottawa,  June  1992 
Response  to  the  Request  from  SGFS  for  Comments  on  Issues  Regarding  Registration  and  ISPs. 
March  1992 
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SC21  N  7199 

SC21  N  7201 
SC21  N  7203 
SC21  N  7204  Rev 

SC21  N  7205 
SC21N7208 
SC21  N  7209 

SC21  N  7214 
SC21  N  7215 
SC21  N  7218 

SC21  N  7268 
SC21  N  7292 
SC21  N  7335 

SC21  N  7336 

SC21N7360 

SC21  N  7375 
SC21  N  7379 

SC21  N  7392 

SC21  N  7417 
SC21  N  7425 
SC21  N  7430 

SC21  N  7483 


SC21N7486 
SC21  N  7566 
SC21  N  7625 
SC21  N  7626 
SC21  N  7644 
SC21  N  7672 
SC21  N  7676 
SC21  N  7713 

SC21  N  7720 
SC21  N  7728 
SC21  H  7747 
SC21N7749 
SC21  N  7817 
SC21N7M1 

SC21  N  7902 
SC21  N  7914 


SC21  N  7915 
SC21  N  7930 

SC21  N  7931 
SC21  N  7932 
SC21  N  7942 
SC21  N  7955 

SC21  N  7957 


Remote  Database  Acceu  (RDA),  ISO  9579,  Put  3:  IRDS  Specialization,  July  1992  [target  due*  are 
WD  (7/94),  CD  (7/95),  DIS  (7/96),  and  IS  (7/97)] 

Amendment  to  ISO  10728  for  C  Language  Binding,  August  1992 
IRDS  Framework  Revision 

Resolutions  of  the  Eight  Plenary  Meeting  of  ISO/IEC  JTC1/SC21,  2-3  June  1992,  Ottawa,  Canada, 
June  1992 

ISO/IEC  JTC1/SC21  Programme  of  Work,  September  1992 

Proposal  for  an  SC21  SWG  on  Modelling  Facilities  (see  also  SC21  N  6945),  June  1992 

Initial  SC21  Considerations  in  Support  of  the  Initiation  of  a  Study  Period  on  Application 

Programmatic  Interfaces,  June  1992 

Rapporteur's  Report  on  SC21  Strategic  Planning,  June  1992 

Revised  Management  Guidelines  for  ISO/IEC  JTC1/SC21,  June  1992 

Table  of  Replies  for  ISO/IEC  9545/DAM  1,  Information  Technology  Open  Systems  Interconnection 
-  Application  Layer  Structure,  Amendment  1:  Extended  Application  Layer  Structure,  June  1992 
Collection  of  Definitions  of  OSI  Vocabulary  (June  1992  version),  July  1992 
Guide  for  Open  Systems  Security,  August  1992  [SC21/WG1] 

Working  Draft  for  LOTOS  Description  of  the  CCR  Protocol,  August  1992  (CD  expected 
December  1992;  DIS  June  1993;  IS  June  1994) 

Working  Draft  for  LOTOS  Description  of  the  CCR  Service,  August  1992  (CD  expected 
December  1992;  DIS  June  1993;  IS  June  1994) 

Development  of  the  SGFS  Procedures  to  Cover  Other  TCs  and  the  Open  System  En  cement  (SGFS 
N  590).  September  1992 

Call  for  Contributions  on  SC21/WG4  Title  and  Terms  of  Reference,  October  1992 

Liaison  Statement  to  SC 21  on  OSI  Profile  Conformance  Requirements  in  TR  10000-1,  October 

1992 

US  Contribution  to  the  SC 21  Special  Working  Group  Meeting  on  Modelling  Facilities. 
7-11  December  1992  in  Namur,  Belgium,  October  1992 
Association  Management  Concepts,  November  1992 

Draft  First  Report  on  the  New  Work  Area  on  Programmatic  Interfaces,  November  1992 
Working  Draft  of  the  Technical  Report  on  Multimedia  and  Hypermedia:  Model  and  Framework, 
Version  1,  October  1992 

Proposal  for  a  New  Work  Item  on  Mapping  of  OSI  System  Management  -  Object  Management 
Function  onto  Message  Handling  Service  (MHS),  December  1992  (WD  expected  in  June  1993,  CD 
in  November  1993,  DIS  in  June  1994,  and  IS  in  June  1995) 

Draft  IRDS  Conceptual  Schema,  December  1992 
Directory  Implementor's  Guide,  Versioo  7,  January  1993 

Status  of  Work  oo  the  Separation  of  Data  and  Commit  Flows  in  OSI-TP,  February  1993 
Request  for  Contributions  for  OSI-TP  Subtransactions,  February  1993 
IP  Commitment  Optimizations  -  Topics  and  Their  Resolution,  February  1993 
Reviled  Working  Draft  for  TP  Test  Suite  Structure,  March  1993 
Initial  Abstract  Test  Suite  for  TP,  March  1993 

Resolutions  of  the  ISO/IEC  JTC1  Plenary  Meeting,  23-26  March  1993,  Berlin.  Germany. 
April  1993 

Revised  Title  and  Scope  for  SC21.  April  1993 

Proposals  for  Re-assessment  or  Cancellation  of  Specific  SC 21  Projects.  April  1993 

Revtaed  Text  of  the  Guide  for  CCTIT  aod  ISO/IEC  JTC1  Cooperation,  April  1993 

The  International  Telecommunication  Union  •  An  Overview,  April  1993 

Requirement  for  Timely  Progression  of  the  Application  Guidelines,  May  1993 

Report  of  the  Ninth  Plenary  Meeting  of  ISOftEC  JTC1/SC  21  to  be  held  from  29-30  June  1993  in 

Yokohama,  Japan,  May  1993 

Methodology  and  Guidelines  for  the  Development  of  Application  Layer  Standards,  June  1993 
Working  Document  oo  Authentication  and  Related  Security  Services,  August  1993  (four  parts  are 
planned:  Introduction  and  Model;  Generic  Abstract  Security  Service;  Specific  Security  Service 
Definhions;  and  Protocol  Specifications)  (CD  expected  December  1994,  IMS  December  1995,  and  IS 
December  1996) 

Liaieon  Statement  to  SC6  in  Reply  to  SC6  N  7961  and  7614,  SC21/WG8,  August  1993 
Working  Document  oo  Use  of  OSI  Systems  Management  for  the  Administration  of  the  Directory, 
June  1993 

Working  Document  oo  the  Internationalization  of  the  Directory,  June  1993 
mu  of  Directory  Operational  Security,  June  1993 
Directory  Scb  sna  Migration,  June  1993  (NWI  Proposal) 

SC21/WG4  Standing  Document  1:  Issues  for  Extended  Systems  Management  Architecture, 
July  1993 

Extended  Systems  Management  Architecture,  July  1993 
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SC21  N  7959 
SC21  N  7962 
SC21  N  7965 
SC21  N  7970 
SC21  N  7980 
SC21  N  7983 
SC21  N  7991 

SC21  N  7992 

SC21  N  7993 

SC21  N7995 

SC21  N  8003 
SC21  N  8004 

SC21  N8005 

SC21  N  8010 

SC21  N  8011 


SC21  N  8013 

SC21  N  8016 

SC21  N  8018 
SC21  N  8019 

SC21  N  8020 
SC21N8022 
SC21  N  8023 
SC21  N  8029 
SC21  N  8030 
SC21N8034 
SC21  N  8097 
SC21  N  8040 
SC21  N  8043  Rev 
SC21N80S6 
SC21  N  8057 

SC21  N  8058 

SC21  N  8059 

SC21  N8060 

SC21  N8061 

SC21  N  8062 

SC21  N  8063 

SC21  N  8064 

SOI  N  8063 

SOI  N  8081 

SOI  N  8103  Rev. 
SOI  N  8109 

SOI  N  8118 


Expiry  Behavior,  aecood  WD.  July  1993 

.  Working  Document  for  Command  Sequencer  for  System!  Management,  July  1993 
Definition  of  Systems  Management  Protocol  Machine  Managed  Objects,  September  1993 
Rnh«.«-H  Functionality  for  Systems  Management  Communications,  June  1993 
Liaison  Statement  to  ITU-TS/SG15  on  Change  Over  Function,  August  1993 
Liaison  Statement  to  S01/WG8  and  SC 27  on  Future  Liaison  Activity,  SC21/WG4,  August  1993 
Liaison  Statement  to  JTC1/SC18,  SC25,  SC27,  S09,  ISO/TC68,  ISO/TC46.  and  J7C1/WG3 
Concerning  Activity  on  Quality  of  Service,  SC21/WG1,  August  1993 

Liaison  Statement  to  ISO/TC 1 84/SC5/WG2  Concerning  Activity  on  Quality  of  Service, 
SC21/WG1.  August  1993 

Quality  of  Service  Framework,  Second  Working  Draft,  August  1993  (rapporteur  meeting  November 
1993;  PDTR  expected  July  1994) 

Working  Draft  on  Formal  Methods  in  Conformance  Testing,  September  1993  (collaborative 
meeting  February  1994;  CD  expected  July  1994) 

NP  on  Architecture  for  Multipeer  Data  Communications,  June  1993 

Liaison  Statement  to  ISO/TC  184/SC5/WG2  on  Question  65.1 — User  Requirements  for  OSI  Systems 
Supporting  Tune  Critical  Communications,  SC21/WG1,  August  1993 

Liaison  Statement  to  ITU-TS/SG7  (Q2/7,  Q19/7,  Q20/7)  on  Quality  of  Service.  SC21/WG1.  August 
1993 

Open  Systems  Assessment  Methodology,  June  1993  (NWI  Proposal;  ballot  ended  November  1993) 
(CD  expected  1993) 

Conformance  Testing  of  OSI  Protocols  over  OSI  Services  Provided  by  Non -OSI  Protocols, 
July  1993  (NWI  Proposal;  ballot  ended  November  1993)  (PDAMs  to  9646-1  to  -7  expected 
June  1995) 

Liaison  Statement  to  JTC1/SWG-CA,  JTC1/SGFS,  EWOS,  OIW.  and  AOW  on  Open  Systems 
Assessment  Methodology,  August  1993 

Extensions  to  ISO  9646  on  Testing  of  OSI  Protocols  over  OSI  Services  Provided  by  Non -OSI 
Protocols,  June  1993  (NWI  Proposal;  ballot  ended  November  1993) 

Liaison  Statement  to  TTU-TS  SG7  (Q19/7)  on  Q1/6S.2 — OSI  Protocols  Efficiency,  August  1993 
Liaison  Statement  to  ITU-TS/SG7  on  Ql/67  -  Generalization  of  A  SO  Concept,  SC21/WG1,  August 
1993 

Liaison  Statement  to  JTC1/SC27  on  Open  Systems  Security,  SC21/WG1,  August  1993 
NP  on  Enhancements  to  LOTOS,  June  1993 

Initial  Draft  on  Enhancements  to  LOTOS,  SC21/WG1,  November  1993 

Liaison  Statement  to  JTC1/SC6  on  Quality  of  Service.  SC21/WG1,  August  1993 

Liaison  Statement  to  EWOS,  OIW,  and  AOW  on  Quality  of  Service.  SC21/WG1.  August  1993 

Liaison  Statement  to  the  Object  Management  Group.  SC21/WG7,  August  1993 

Issues  for  Management  Domain  Management  Function.  June  1993 

Relationship  Management  Function,  Second  Working  Document.  June  1993 

Report  of  die  SC21  Study  Group  on  APIs,  Revised,  June  1993. 

SC21  SWG-MF  Meeting,  June  1993,  Yokohama,  July  1993 

Recommend atioD  to  Progress  Work  on  the  Use  of  Standard  Data  Modelling  Facilities  in  foe 
Preparation  of  International  Standards,  SWG-MF,  July  1993 

Final  Recommendations  of  the  SC21  Special  Working  Group  on  Modelling  Facilities  (SWG-MF), 
SWG-MF,  July  1993 

Response  to  the  SC21  Chairman  from  the  SC21  Special  Working  Group  on  Modelling  Facilities 
(SWG-MF).  SWG-MF,  July  1993 

Conceptual  Schema  Modeling  Facility,  June  1993  (NWI  Proposal;  ballot  ended  November  1993) 
(rapporteur  meeting  January  1994) 

SC21  Special  Working  Group  on  Modelling  Facilities  (SWG-MF)  Response  to  ISCVIEC  JTC1/SC18 
Liaison  Statement,  SWG-MF,  July  1993 

SC21  Special  Working  Group  on  Modelling  Facilities  (SWG-MF)  liaison  Statement  to  ISCVIEC 
JTC1/SC14,  SWG-MF,  July  1993 

SC21  Special  Washing  Group  on  Modelling  Facilities  (SWG-MF)  Response  to  ISCVIEC  JTC1/WG3 
Open  edi  Liaison  Report,  SWG-MF,  July  1993 

SC21  Special  Working  Group  on  Modelling  Facilities  (SWG-MF)  Response  to  ISCVTC46/SC4 
Liaison  Statement,  SWG-MF,  July  1993 

SC21  Special  Working  Group  on  Modelling  Facilities  (SWG-MF)  Response  to  JTC1/SC21/WG7 
Liaison  Statement,  SWG-MF,  July  1993 

Resolutions  of  the  Ninth  Plenary  Meeting  of  ISCVIEC  JTCl/SC  21,  29-30  June  1993,  Yokohama, 
Japan,  June  1993 

Request  from  SC21  to  JTC1  Concerning  the  “Fast  Tracking'*  of  foe  PCTE  Document,  June  1993 
Proposed  New  Question  Q3/0U,  “Harmonization  of  Clwnt/Server  Capabilities,"  SC21/WG3, 
September  1993 

Report  from  the  SC 21  ISP  Meefoig,  23  June  1993.  Yokohama.  June  1993 
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SC21  N  8122  Management  Guideline*,  June  1993 

SC21  N  8122  Update  to  Management  Guideline*  on  Formal  Description*,  SC21,  June  1993 

SC21  N  8127  Liaison  Information  on  Modelling  Facility  Interim  Work,  SC21  SWG-MF,  June  1993 

SC21  N  8128  Liaison  Statement  to  the  Internet  Society,  SC21,  June  1993 

SC21  N  8129  Statement  of  Benefits  on  Establishment  of  C-Liaison  with  X/Open,  SC21,  June  1993 

SC21  N  8130  Statement  of  Benefits  on  Establishment  of  C-Liaison  with  the  Object  Management  Group  (OMG), 

SC21,  June  1993 

SC21  N  8131  Statement  of  Benefits  on  Establishment  of  C-Liaison  with  the  Internet  Society,  SC21,  June  1993 

SC21  N  8151  Status  of  Work  on  the  Subtransactioos  in  OSI  TP,  SC21/WG8,  July  1993 

SC21  N  8152  Status  of  Work  on  the  Separation  of  Data  and  Commit  Flows  in  OSI  TP,  SC21/WG8,  July  1993 

SC21  N  8161  Working  Draft  on  Enhancements  to  Metric  Objects  and  Attributes,  SC21/WG4,  July  1993 

SC21N8162  Working  Draft  for  ICS  Proforma  for  Metric  Objects  and  Attributes.  SC21/WG4,  July  1993 

SC21  N  8163  Working  Draft  for  ICS  Proforma  for  Summarization  Function,  SC21/WG4,  July  1993 

SC21  N  8173  Information  Processing  Systems  -  Open  Systems  Interconnection  •  Basic  Presentation  Service 

Definition,  review  text  of  the  Edition  2  of  ISO  8822,  August  1993 
SC21  N  8174  Information  Processing  Systems  -  Open  Systems  Interconnection  •  Basic  Connection  Oriented 

Presentation  Protocol,  Part  1:  Protocol  Specification,  review  text  of  the  Edition  2  of  ISO  8823-1, 
August  1993 

SC21  N  8178  Working  Document  on  Managed  Objects  for  Upper  Layers,  August  1993 

SC21  N  8192  Working  Document  on  Topic  9.1  -  OOP  Trader,  August  1993  (CD  expected  July  1994) 

SC21N8193  Status  of  JLSeries  Recommendations,  ITU-TS  SG7,  August  1993 

SC21  N  8202  Working  Draft  on  RDS  Services  Interface  Extensions,  September  1993 

SC21  N  8204  Working  Draft  on  RDS  Framework  Standard  (Revision  of  ISO  10027:1990),  September  1993 

SC21  N  8205  SQL  Multimedia  and  Hypermedia  Application  Packages  (SQL/MM)  Project  Plan  (Revised), 

SC21/WG3,  September  1993 

SC21  N  8211  Draft  Answer  to  Question  Q 3/007,  “Support  for  Distributed  Database  Systems,”  SC21/WG3, 

September  1993 

SC21  N  8216  Working  Draft  of  Conformance  Test  Suite  for  the  TP  Protocol,  Part  1:  Test  Suite  Structure  and  Test 

Purposes,  September  1993  (CD  expected  July  1994) 

SC21  N  8218  Working  Draft  for  Information  Technology  -  Open  Distributed  Processing  -  Basic  Reference  Model 

of  ODP,  Part  1:  Overview  and  Guide  to  Use,  September  1993 

SC21  N  8249  Rules  of  Procedure  and  Working  Method*  of  the  ITU  Telecommunication*  Standardization  Sector  end 

Study  Group  Responsibility  and  Mandates,  ITU-TS,  October  1993 
SC21  N  8251  Proposed  Approval  of  27  Recommendations  Agreed  to  by  Study  Group  7  at  it*  Meeting  an  2  July 

1993,  ITU-TS,  October  1993 

SC21  N  8256  Disposition  of  Comments  Report  and  Final  Work  Item  Definition  for  “Engagement  Scheduling  and 

Recording  Application  within  the  Distributed  Office  Application*  Model  (DO AM),"  October  1993 
SC2IN82S6  Liaison  Statement  Reganlmg  FTAM  Abstract  Test  Suites,  EWQS/EG  FT,  October  1993 

SC21  N  8258  Corrected  Liaison  Statement  to  SC21  Entitled.  “Comments  on  the  First  Draft  Report  on  the  New 

Work  Area  on  Programmatic  Interfaces,”  SC  18,  October  1993 
SC21  N  8260  Liaison  to  SC21  on  the  Character,  Graphic  Symbol  rod  Glyph,  SC18/WG8,  October  1993 

SC21  N  8261  Liaison  Between  SC24  and  SC21,  SC24,  October  1993 

SC21  N  8262  Liaison  Statement  to  SC21  and  SC6  on  OSI  Quality  of  Service,  ITU-TS  SG7,  October  1993 

SC21  N  8263  Liaison  Statement  to  SC21  and  SC6  on  OSI  Quality  of  Service  Framework  Specification*.  ITU-TS 

SG7,  October  1993 

SC21  N  8264  liaison  Statement  to  SC21/WG1  Conformance  Group  on  Collaborative  Work,  ITU-TS/SG7,  October 

1993 

SC21  N  8265  Liaison  Statement  to  SC21  on  OSI  Service  Conventions,  ITU-TS  SG7,  October  1993 

SC21  N  8266  liaison  Statement  to  SC21  on  OSI  Reference  Model  ITU-TS  SG7,  October  1993 

SC21  N  8267  Liaison  Statement  to  SC21  on  OSI  Multicast  Architecture,  ITU-TS  SG7,  October  1993 

SC21  N  8268  liaison  Statement  to  SC21  WGs  1  and  8  on  OSI  Protocol  Efficiency  to  ICG  on  Satellite  Matters, 

SG8,  SG11,  SG13,  ISO/IEC  JTC1/SC21  (WGs  1  and  8),  and  ISO/JTC1/SG6,  ITU-TS  SG7,  October 
1993 

SC21  N  8269  liaison  Statement  to  SC21  WG/8  on  Security  Activities.  ITU-TS  SG7,  October  1993 

SC21N8270  Liaison  Statement  to  SC21  WG/8  on  the  ROSE  Standard,  ITU-TSSG7,  October  1993 

SC21  N  8280  liaison  Statement  to  SC21/WG4  on  Requirements  and  Directions  for  the  Use  of  Formal  Description 

Techniques  for  the  Specification  of  Managed  Objects,  ITU-TS  SG7,  October  1993 
9C2I  N  8281  Liaison  Statement  to  SC21/WG4  Concerning  the  OSI  Systems  Management  Implementor's  Guide, 

ITU-TS  SG7,  October  1993 

SC21  N  8282  Calling  Notice  and  Draft  Agenda  for  the  Interim  Meeting  of  the  SC21/WG3  Rapporteur  Group  on 

Conceptual  Schema  Modelling  Facilities,  Aix  en  Provence,  17-21  Jammy  1994,  October  1993 
SC21  N  8285  Position  on  the  ODP  Standards  Process  and  Cooperation  with  de  facto  Standards  Organizations, 

AFNOR,  October  1993 

SC21N8305  A  Date  Modelling  Facility:  JDMF/MODEL-1992,  Japan.  October  1993 
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SC21  N  >315 

SC21  N  >316 
SC21  N  >318 
SC21  N  >320 
SC21  N  >321 
SC21  N  >322 
SC21  N8325 

SC21  N8326 

SC21  N  8327 

SC21  N  8328 

SC21N  8329 

SC21  N  8330 

SC21  N  >355 
SC21  N  >356 
SC21  N  8380 
SC21  N8382 

SC21  N  8383 

SC21  N  8384 

SC21  N  8385 

SC21N8397 

SC21N8409 
SC21  N  8410 


Question  on  Registration  of  Names  of  International  Organization!  for  Directory.  USA,  October 
1993 

Comment*  on  Standardized  Programmatic  Interface*.  USA,  October  1993 

Establishment  of  Formal  Liaison  Between  JTC1/SC21  Mid  JTC1/SC29,  SC29,  December  1993 

UK  Position  on  Programmatic  Interface  Standmdization,  UK,  November  1993 

Requirement  for  Partial  Rollback.  USA,  November  1993 

Response  to  SC 21  N  8067  on  TP  with  RPC,  USA,  November  1993 

Authentication  and  Privilege  Attribute  Security  Application  with  Related  Key  Distribution 
Functions,  Part  1:  Overview  and  Functional  Model,  ECMA/TC-TQ9,  November  1993 
Authentication  and  Privilege  Attribute  Security  Application  with  Related  Key  Distribution 
Functions,  Part  2:  Security  Information  Objects,  ECMA/TC-TG9,  November  1993 
Authentication  and  Privilege  Attribute  Security  Application  with  Related  Key  Distribution 
Functions,  Part  3:  Service  Definitions,  ECMA/TC-T09,  November  1993 

Liaison  Statement  to  SC21/WG8  Regarding  Authentication  and  Related  Security  Services  for 
Distributed  Application s,  ECMA/TC-TG9,  November  1993 

Liaison  Contribution  to  SC21/WG8  Regarding  Authentication  and  Related  Security  Services  for 
Distributed  Applications  -  Extended  Schematic  for  First  Draft,  ECMA/TC-TG9,  November  1993 
Version  V2  of  the  APA-Application  Standard,  ECMA/TC-TG9,  November  1993  (standard  haa  thiee 
parts:  Overview  and  Functional  Model,  Security  Information  Objecta,  and  Service  Definitions) 
liaison  Statement  to  SC21/WG1  and  SC22/WG15  on  Conformance  Testing,  December  1993 
Draft  Technical  Corrigenda  to  ISO  8571,  FT AM,  December  1993 
Guide  to  Open  System  Security,  Working  Draft  Technical  Report  December  1993 
Liaison  Statement  to  SC21/WG4  on  Management  of  Time  Critical  Communications, 
ISOOC184/SCS/WG2,  December  1993 

Liaison  Statement  to  SC21/WG1  on  Question  65.1 — User  Requirements  for  OSI  Systems 
Supporting  Time  Critical  Communications,  ISO/TCI  84/SC5/WG  2,  December  1993 
Liaison  Statement  to  SC21/WG1  on  Multi-Peer  Data  Transmission,  ISO/TC 1 84/SC5/WG  2, 
December  1993 

final  Draft  Version  of  TCCA  Technical  Report  (DTK  12178)  Sent  to  the  ISO  Central  Secretariat  for 
Publication,  ISCVTC184/SCS/WG2,  December  1993 

Outline  Contribution  to  Future  Work  as  Proposed  in  SC21  N  8045  Rev  2,  SC 21  SWG-SFI  Meeting 
8-11  November  1993  in  Totina,  January  1994 

Information  Technology  -  Open  Systems  Interconnection  -  ODP  Trading  Function,  January  1994 
Methodology  and  Guideline*  for  foe  Development  of  Application  Layer  Protocols,  January  1994 


DOCUMENTS  OF  SC21  WORKING  GROUPS 

SC21/WG1  N  1140  UK  Discussion  Paper  on  Conformance  Testing  for  OSI  Security 
SC21/WG1  N  1156  Clarification  on  Use  of  the  PICS 
SC21/WG1  N  1157  Contributions  on  LOTOS  Enhancements 
SC21/WG1  N  1253  Use  of  Quality  of  Services  in  ODP  Trader,  May  1993 


SC21/WQ3  N 
SC21/WG3  N 
SC21/WG3  N 
SC21/WG3N 

SC21/WG3  N 
SC21/WG3  N 
SC21/WG3  N 
SC21/WG3  N 
SC21/WQ3  N 
SC21/WG3N 
SC21/WG3N 
SC21/WG3  N 

SC21/WG3  N 

SC21/WG3  N 

SC21/WG3  N 
SC21  WQ3N 

SC21/WG3N 


1279  Report  of  Meeting  CDIF/1175/PDES  Information  Coordiaatioo 
1283  IRDS  Services  Interface  Extensions  -  Design  Document 
1298  New  Project  Proposal:  SQL  ADT  Packages 

1345  Letter  to  Convenor,  Government  Telecommunication*  Agency/VPD,  Ottawa  Canada.  EWOS,  Expert 
Group  on  Database  Enquiry 

1349  Liaison  Report  June  1991-May  1992,  JTC1/SC7  Software  Engineering 
1371  Discussion  between  JTC1  SC21/WG3  and  ISO  TC  184/SC5/WG4 
1406  Agreed  Scope  of  Work  for  the  Revisioo  of  the  IRDS  Framework  (IS  10Q27X  Ottawa 

1430  DBL  Stains  Report 

1557  Rev  Proposal  for  the  Registration  of  Q3/010:  ODP  and  Distributed  Database  Systems,  June  1993 

1581  Distributed  DeU  and  the  Scope  of  Federated  Database  Systems,  June  1993 

1586  Views  on  the  Relationship  Between  foe  ODP  Trader  and  Data  Management,  June  1993 

1613  ISO  SQL  Multimedia  and  Application  Packages  (SQL/MM),  Part  2:  Full-Text,  Working  Draft. 
September  1993 

1614  ISO  SQL  Multimedia  and  Application  Packages  (SQL/MM),  Part  3:  Spatial,  Working  Draft, 
September  1993 

1644  Technical  Report  on  the  Semantic  Unification  of  Meta-Model,  Volume  1,  Semantic  Unification  of 
Static  Models,  US  National  Body,  November  1993 

1645  Knowledge  Interchange  Format  (UF),  US  Natiooal  Body,  Nnovember  1993 

1646  Propoeed  Working  Draft  for  Base  Document  for  Conceptual  Schema  Modelling  Facilities, 
October  1993 

1647  ISO  SQL  Multimedia  and  Application  Packs  gee  (SQL/MM),  Part  1:  Framework.  Working  Draft, 
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Proposals  for  Changes  to  SC21/WG6  Programme  of  Work 

Provision  of  Guidance  on  Application  of  XALS  Concepts 

Strawman  Generic  Security  ESO-OS1  Abstract  Interface 

Proposal  for  a  New  Work  Item  oo  a  Class  of  Mappings  from  a  Single  ASN.l  Type  to  an  FTAM 
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Job*  Action  Pirn  SC21/WG7  and  WG7-1TU-TS/Q16/?  (TTU-TS  Format).  August  1993 
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Authentication  and  Related  Security  Services,  Part  2:  Generic  Abstract  Services  for  Security 
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LAPB  Extended  for  Half-Dupisx  Phyrical  Level  Facility 
Totaal  CXpaNHtiae  for  Mixed  Mod*  of  Operation 
Doc  — t  Interchange  Protocol  for  the  Tclutic  Service* 

Coded  Rapresentetion  of  Picture  eod  Audio  Infonnatioa-Progressive  Bi-lerel  Image  Cotnpraaiioa 
TiIiUt  Requiraaeenti  for  Internetworkiiif  with  the  Tele*  Service 

Teletex  Requirement*  for  Reel-Time  Internetworking  with  the  Telex  Service  in  e  Packet-Switching 
Network  Environment 

International  Interworking  for  Videotex  Services 
Protocols  for  Syntax-Besed  Videotex  U*ing  ISDN  Circuit  Mode 
Protocols  for  Syntax-Based  Videotex  Using  ISDN  Packet  Mode 
Packet  Mode  Access  for  Syntax-Based  Videotex  Via  PSTN 
Syntax-Based  Videotex  Application  Layer  Protocol 
Rramewotk  for  Videotex  Teradnal  Protocols 
Multipoint  Communications  Service 

Protocol  Stacks  For  AndiograpUc  And  Audiovisual  Teleconference  Applications 
Telematic  Access  to  Interpersonal  Massaging  System 
Introduction  to  Document  Architecture,  Transfer  and  Manipulation 

First  extension  (January  1991)  to  the  T.410  Series  (19M)  of  Recommendations  contained  in  the 
Blue  Book,  Fascicle  VII. 6 

Open  Document  Architecture  (ODA)  and  Interchange  Format  -  Introduction  and  General  Principles 
(sss  ISO  8613-1) 

Open  Document  Architecture  r  '  >A)  and  Interchange  Format  -  Document  Shnctans  (see  ISO  1613-2) 
Open  Document  As  Me  (ODA)  and  Interchange  Format  -  Document  Profile  (me  ISO  >613-4) 
Open  Document  At...  vture  (ODA)  and  Intatchange  Fermat  -  Open  Document  Interchange  Format 
(ODiF)  (aee  ISO  1613-2, 

Open  Document  Architecture  (ODA)  end  Interchange  Format  -  Character  Content  AuhltecUsrae  (see 
ISO  1613-6) 

Open  Document  AicMtsctme  (ODA)  md  Interchange  Format  -  Restar  Graphics  Content  Architectures 
(see  ISO  1613-7) 

Open  Document  Architecture  (ODA)  and  Interchange  Format  -  Geometric  Graphics  Coolant 
Architectures  (sss  ISO  16134) 

Documsut  TV— far  and  Manipulation  (DTAM)  -  Composite  Graphics  Content  ArcMtectume 
Document  Transfer  md  Manipulation  (DTAM)  -  Services  and  Protocols,  Introduction  md  General 
Principles 

Do  ram  ant  Transfer  and  Manipulation  (DTAM)  -  Services  and  Protocols.  Service  Definition 
Document  Transfer  and  Manipulation  (DTAM)  -  Services  and  Protocols.  Protocol  Specification 
Docnmmt  Transfer  and  Manipulation  (DTAM)  -  Operations!  Stnschm 

Document  Application  Profile  MM  for  the  Interchange  of  Formatted  Mixed  Mode  Documents  (Mixed 
Mods) 


TJU  Rev  1  Documsut  Application  Profile  PM  11  for  the  Interchange  of  Processahle  Form  Documents  (Matas 

*  Piroctciibk  Morin) 

TJ®3  A  Doraraent  Application  Profile  for  the  Interchange  of  Group  4  Facsimile  Docaments 

T504  Rev  1  rtimimnnl  Application  Profile  for  Videotex  Interworking 

TiQS  Document  application  profile  PM-26  for  the  interchange  of  mixed  content  documents  in 

procassaMs  and  format  form* 

TJ10  Rev  1  Overview  of  mh-earios  T310  Recommendations 

T.321  Communication  Application  Profile  BTO  for  Docnmmt  Bulk  Transfer  Based  on  tbs  Session  Sarvies 

(According  to  Rules  Defined  in  T.62  Ms) 

TJ22  Oommmicstion  Application  Profils  BT1  for  Docummt  Bulk  Transfer 

T-523  Rev  1  Co— am Intirr  Application  Profile  DM-1  for  Videotex  Iaterworidag 

TJ41  Rev  1  Operational  Application  Profile  for  Videotex  Iutenrorking 

TJ61  T— Inal  Characteristics  for  hfixed  Mode  of  Operation  MM 

TJ62  Terminal  Characteristics  for  Tslstsx  Processing  Mods  PM1 

TJ63  Rev  1  Tsrmhtel  Characteristics  for  Group  4  Facsimile  Apparatus 

TJ64  Rev  1  Gateway  Characteristict  for  Videotex  Interworking 


S.  m)-T8  V-8EKIES 

V.le  Equivalence  Between  Binary  Notation  Symbols  and  Sign,  Condition  of  a  Two-Condition  Cods 

VAe  xwnrtw  eip.i.  ri  At|*^—  Mr.  3  Cods  for  Date  TTmsatiasloa  over  PTN 
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VJe 

V.6« 


V.7e 

V.l(yx.26  Rev  le 

V.11/X.27  Rev  1* 

V.I3 

V.W 

V.17 

V.20 


V.24  Rev  U 
V.25 


V.25  bis 

V.2S  Rev  W 
V.31 
VJ1  bis 
V32  Rev  1 

V.32  bis 

V35* 

V36e 

V37e 

V3» 

V.42  Rev  1 
V.42  Ms 

V.54 


Standardization  of  Dele  Signalling  Rales  for  Syocbroooas  Dele  Transmission  in  the  General 
Switched  TN 

Standardisation  of  DeU  Signalling  Rues  for  Synchronous  Data  Transmission  on  Leased  Tekpbooe- 
Type  Circnits 

Definition  of  Terms  Concerning  Dels  Communication  over  Telephone  Network 

Electrical  Characteristics  for  Unbalanced  Double-Current  Interchange  Circnits  for  General  Use  with 

Integrated  Circuit  Equipment  in  the  Field  of  Data  Communication 

Electrical  Characteristics  for  Balanced  Double-Current  Interchange  Circuits  for  General  Use  with 
Integrated  Circuit  Equipment  in  the  Field  of  Data  Communications 
*>inwlHfw1  Curicr  Control 

Transmission  of  Start-Stop  Characters  over  Synchronous  Bearer  Channels 

A  2-Wire  Modem  for  Facsimile  Applications  With  Rales  19  to  14.400  bit/s 

Telex  and  Centex  Signalling  on  Radio  Channels  (Synchronous  7-Unit  Systems  Affording  Error 

Correction  by  Automatic  Repetition) 

List  of  Definitions  for  Interchange  Circuits  Between  DTE  and  DCE 

Automatic  Answering  Equipment  and/or  Parallel  Automatic  Calling  Equipment  on  the  General 
Switched  Telephone  Network  Including  Procedures  for  Disabling  of  Echo  Control  Devices  for  Both 
Manually  and  Automatically  Established  Calls 

Automatic  Calling  and/or  Answering  Equipment  on  the  Geoeral  Switched  Telephone  Network 
(GSTN)  Using  the  100-Series  Interchange  Circuits 

Electrical  Characteristics  for  Unbalanced  Double-Current  Interchange  Circuits 

Electrical  Characteristics  for  Single-Current  Interchange  Circuits  Controlled  by  Contact  Cloeure 

Electrical  Characteristics  for  Single-Current  Interchange  Circuite  Using  Opto  Couplers 

A  Family  of  2-Wire,  Duplex  Modems  Operating  at  Data  Signaling  Rales  of  up  to  9.600  bit/s  for  Use 

on  the  General  Switched  Telephone  Networic  and  on  Leased  Telephone-Type  Circuits 

A  Duplex  Model  Operating  at  Data  Signalling  Rales  of  up  to  14.400  bit/a  for  Uae  00  the  General 

Switched  Telephone  Network  and  on  Leased  Point -to- Point  2-Wire  Telephone-Type  Circuits 

Data  Transmission  at  48  kbit/s  Using  60-108  kHz  Group  Band  Circuits 

Modems  for  Synchronous  Data  Transmission  Using  60-108  kHz  Group  Band  Circuits 

Synchronous  Data  Transmission  at  a  Data  Signalling  Rato  Higher  than  72  kbit/s  Using  60-108  kHz 

Group  Band  Circuits 

A  48/56/64  kbit/s  Data  Circuit  Terminating  Equipment  Standardized  for  Use  Ou  Digital  Point-to- 
Point  Leased  Circuits 

Error-Correcting  Procedures  for  DCBs  Using  Asyncbrooons-<o-Syncbronons  Conversion 

Data  Compression  Procedures  For  Data  Circuit  Terminating  Equipment  (DCE)  Using  Error 

Correcting  Procedures 

Loop  Test  Devices  for  Modems 


F.  ITU-TS  X-SERIES5 


PUBLIC  DATA 
X.1  Rev  le 

X.2  Rev  1 

X 3  Rev  1 
X.4 

X.5 

X.6 

X.7 

X.IOe 

Xeep 

X.asp+ 

X.atc 

X-msp 


NETWORKS:  Services  and  Facilities 

User  Claeses  of  Service  in  and  Categories  of  Access  to  Public  Data  Networks  and 
Services  Digital  Networks  (ISDNs),  1993 

International  Data  Transmission  Services  and  Optional  User  Facilities  in  Public  Data  Networks  and 
ISDNs,  1993 

Packet  Asmmbly/Disieeembly  Facility  (PAD)  in  s  Public  Data  Network  (PDN).  1993 
General  Structure  of  Signals  of  International  Alphabet  No.  5  Code  for  Data  Transmission  over 
Public  Data  Networks,  1988 

Facsimile  Packet  Assembly/Disassembly  Facility  (FPAD)  in  a  Public  Data  Network,  1992 
Multicast  Service  Definition,  1993 

Technical  Characteristics  of  Data  Transmission  Services,  1993 

Categories  of  Access  for  Data  Terminal  Equipmaut  (DTE)  to  Public  Data  Transmission  Services, 
1993 

Mum-Aspect  PAD  Protocol  Defiatfout-l,  Draft,  1993  (approval  target  November  1994) 
Multi-Aspect  PAD  Protocol  Definitions- 2,  Draft,  1993  (approval  target  1996) 

Address  Translation  Capability  fat  Public  Data  Networks,  Draft,  1993  (approval  target  November 
1994) 

Mum-Aspect  PAD  Hmnework,  Draft,  1993  (approval  target  Februvy  1994) 


5  Updated  from  [SC21  N 1193  1993)  (as  of  July  1993). 
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PUBLIC  DATA 
X.20  lUv  1 

X.20  bit 

X.2U 
X.21  bit* 

X.22 

X.24* 

X.25  Rev  1* 

X.26/V.10* 

X.27/V.11* 

X28  Rev  1 

X.29  Rev  I 

X.3G/I.461  Rev  1 
X3 1/1.462  Rev  1* 
X.32  Rev  1* 

X.35 


X.38 


X.39 


X.3x 


XJSni 

X.itp 

Xjncp 

X.mcp* 

X.  mpc 

PUBLIC  DATA 
X.50 


X.SObit 

X.31 

X.Slbit 

XJ2 

X.53  Rev  l 

X.54 

X.35 

X.56 

X.37 

X.58 


X.60 

X.61/Q.741 

Appendix  E 


NETWORKS:  Interfaces 

Interface  Between  DTE  and  DCE  far  Surt -Stop  Tranunitiion  Servicet  on  Piddle  Data  Networks, 
1988 

Ute  on  Public  Data  Networki  of  DTE  which  it  Designed  for  Interfacing  to  Atynchronoot  Duplex 
V-Seriet  Modems,  1988 

Interface  Between  DIE  and  DCE  for  Synchronous  Operation  on  Public  Data  Networks,  1992 

Ute  on  Public  Data  Networks  of  DTE  which  it  Designed  for  Interfacing  to  Synchronous  V -Series 

Modems,  1988 

Multiplex  DTE/DCE  Interface  for  User  Classes  3-6, 1988 

List  of  Definitions  for  Interchange  Circuits  Between  DTE  and  DCE  on  Public  Data  Networks,  1988 
Interface  Between  DTE  and  DCE  for  Terminals  Operating  in  the  Packet  Mode  and  Connected  to 
Public  Data  Networks  by  Dedicated  Circuit,  1988  (Revised  Edition,  1993) 

Electrical  Characteristics  for  Unbalanced  Double-Current  Interchange  Circuits  for  General  Use  with 
Integrated  Circuit  Equipment  in  the  Field  of  Data  Communications.  1993 

Electrical  Characteristics  for  Balanced  Double-Current  Interchange  Circuits  for  General  Use  with 
Integrated  Circuit  Equipment  in  the  Field  of  Data  Communications,  1993 

DTE/DCE  Interface  for  a  Start/Stop  Mode  DTE  Accessing  the  PAD  in  a  PDN  Situated  in  the  Same 
Country,  1993 

Procedures  for  the  Exchange  of  Control  Information  and  User  Data  Between  a  PAD  Facility  and  a 
Packet  Mode  DTE  or  Another  PAD,  1993 

Support  of  X.21,  X.21  bis,  and  X-20  bis  Based  Data  Terminal  Equipments  (DTEs)  by  an  ISDN,  1993 
Support  of  Packet  Mode  Terminal  Equipment  by  an  ISDN,  1993 

Interface  Between  DTE  and  DCE  for  Terminals  Operating  in  the  Packet  Mode  and  Accessing  a  Packet 
Switched  PDN  Through  a  Public  Switched  Telephone  Network  or  a  Circuit  Switched  PDN.  1993 
Interface  Between  a  PSPDN  and  a  Private  PSDN  which  is  Based  on  X.2S  Procedures  and 
Enhancements  to  Define  a  Gateway  Function  that  is  provided  in  the  PSPDN,  Draft  (TTU-TS  balloting 
ended  November  1993) 

G3  Facsimile  Equipmeni/DCE  Interface  for  G3  Facsimile  Equipment  Accessing  the  Facsimile  Packet 
Assembly/Disassembly  Facility  (FPAD)  in  a  Public  Data  Network  Situated  in  the  Same  Country, 
1992 

Procedures  for  the  Exchange  of  Control  Information  and  User  Data  Between  a  Facsimile  Packet 
Assembly /Disassembly  (FPAD)  Facility  and  a  Packet  Mode  DTE  or  Another  FPAD.  1992 
Access  to  Packet  Switched  Data  Transmission  Services  Provided  by  PSPDN  or  ISDN  via  name 
Relaying  PDNs  or  ISDN  Providing  Frame  Mode  Bearer  Service,  Draft.  1993  (approval  target 
November  1994) 

Interface  Between  DTE  and  DCE  for  Public  Data  Network  Proving  Frame  Relay  Data  Transmission 
Service,  Draft,  1993  (approval  target  November  1994) 

Inter-Service  Protocol  for  a  Multicast  Service.  Draft,  1993  (approval  target  June  1993) 

Procedures  for  the  Provision  of  a  Basic  Multicast  Service  for  DCEs  Operating  Using 
Recommendation  X.23,  Draft,  1993  (approval  target  November  1994) 

Procedures  for  the  Provision  of  an  Enhanced  Multicast  Service  for  DCEs  Operating  Using 
Recommendation  X.23  and  Requiring  Additional  Protocol,  Draft,  1993  (approval  target  1996) 
Encapsulation  in  X.23  Packets  of  Various  Protocols  Including  Frame  Relay,  Draft.  1993  (approval 
target  November  1994) 

NETWORKS:  Transmission,  Signalling,  and  Switching 

Fundamental  Parameters  of  a  Multiplexing  Scheme  for  the  International  Interface  Between 
Synchronous  Data  Networks,  1988 

Fundamental  Parameters  of  a  48-kbit/s  User  Data  Signalling  Rate  Transmission  Scheme  for  the 
International  Interface  Between  Synchronous  Data  Networks,  1988 

Fundamental  Parameters  of  a  Multiplexing  Scheme  for  the  International  Interface  Between 
Synchronous  Data  Networks  Using  10-bit  Envelope  Structure,  1988 

Fundamental  Parameters  of  a  48-kbit/s  User  Data  Signalling  Rale  Transmission  Scheme  for  the 

International  Interface  Between  Synchronous  Data  Networks  Using  10-bit  Envelope  Structure,  1988 

Method  of  Encoding  Anisochrooous  Signals  into  a  Synchronous  User  Bearer,  1988 

Numbering  of  Channels  on  International  Multiplex  links  at  64  kbit/s,  1993 

Allocation  of  Channels  on  International  Multiplex  Links  at  64  kbit/s,  1988 

Interface  Between  Synchronous  Data  Networks  Using  a  6*2  Envelope  Structure  and  Single  Channel 

Per  Carrier  (SCPC)  Satellite  Channels,  1988 

Interface  Between  Synchronous  Data  Networks  Using  so  8*2  Envelope  Structure  and  Single  TTiannil 
Par  Carrier  (SCPC)  Satellite  Channels,  1988 

Method  of  Transmitting  a  Single  Lower  Speed  Data  Channel  on  a  64  kbit/s  Data  Stream,  1988 
Fundamental  Parameters  of  a  Multiplexing  Scheme  for  the  International  Interface  Between 
Synchronous  Non-S witched  Data  Networks  Using  No  Envelope  Structure,  1988 
Common  Channel  Signalling  for  Circuit  Switched  Data  Applications,  1988 
Signalling  System  No.  7  •  Data  User  Part,  1988 
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X.70  Terminal  and  Transit  Control  Signalling  System  for  Start-Stop  Services  on  International  Circuits 

Between  Anisochronous  Data  Networks.  1988 

X.71  Decentralized  Terminal  and  Transit  Control  Signalling  System  on  International  Circuits  Between 

Synchronous  Data  Networks,  1988 

X.7S  Rev  1«  Packet-Switched  Signalling  System  Between  Public  Networks  Providing  Data  Transmission 

Services,  1988  (Revised  Edition.  1993) 

X.7x  Signalling  System  Between  Public  Networks  Providing  Frame  Relaying  Data  Transmissional 

Services,  Draft,  1993  (approval  date  November  1994) 

X.80  Interworking  of  Interexcbange  Signalling  Systems  for  Circuit  Switched  Data  Services,  1988 

X.81  Interworking  Between  an  ISDN  Circuit-Switched  and  a  Circuit-Switched  Public  Data  Network 

(CSPDN),  1988 

X.82  Detailed  Arrangements  for  Interworking  Between  CSPDNs  and  PSPDNs  Based  on 

Recommedation  T.70,  1988 
PUBLIC  DATA  NETWORKS:  Network  Aspects 

X.92  Hypothetical  Reference  Connections  for  Public  Synchronous  Data  Networks,  1988 

X.96  Rev  1  Call  Progress  Signals  in  Public  Data  Networks,  1993 

X.l  10  International  Routing  Principles  and  Routing  Plan  for  Public  Data  Networks,  1988 

X.121  International  Numbering  Plan  for  Public  Data  Networks,  1992 

X. 122/E. 166  Numbering  Plan  Interworking  for  the  E.164  and  X.121  Numbering  Plans,  1992 

X.130  Call  Processing  Delays  in  Public  Data  Networks  when  Providing  International  Synchronous  Circuit- 

Switched  Data  Services,  1988 

X.131  Call  Blocking  in  Public  Data  Networks  when  Providing  International  Synchronous  Circuit-Switched 

Data  Services,  1988 

X.134  Portion  Boundaries  and  Packet  Layer  Reference  Events:  Basis  for  Defining  Packet-Switched 

Performance  Parameters,  1992 

X.13S  Speed  of  Service  (Delay  and  Throughput)  Performance  Values  for  Public  Data  Networks  when 

Providing  International  Packet-Switched  Services,  1992 

X.136  Accuracy  and  Dependability  Performance  Values  for  Public  Data  Networks  when  Providing 

International  Packet-Switched  Services,  1992 

X.137  Availability  Performance  Values  for  Public  Data  Networks  when  Providing  International  Packet- 

Switched  Services,  1992 

X.138  Measurement  of  Performance  Values  for  Public  Data  Networks  when  Providing  International  Packtt- 

S witched  Services,  1992 

X.139  Echo,  Drop,  Generator  and  Test  DTEs  for  Measurement  of  Performance  Values  for  Public  Data 

Networks  when  Providing  International  Packet-Switched  Services.  1992 
X.140  General  Quality  of  Service  Parameter  for  Communication  Via  Public  Data  Networks,  1992 

X.141  General  Principles  for  the  Detection  and  Correction  of  Errors  in  Public  Data  Networks.  1988  (with 

corrections) 

XJrq  User  Information  Transfer  Parameters  and  Specifications  for  Data  Networks  Providing  International 

Frame  Relay  PVC  Service,  Draft,  1993  (approval  date  November  1994) 

PUBLIC  DATA  NETWORKS:  Maintenance 

X.130  Principles  of  Maintenance  Testing  for  Public  Data  Networks  Using  DTE  and  DCE  Test  Loops,  1988 

X.l 60  Architecture  for  Customer  Network  Management  Services  for  Public  Data  Networks.  Draft,  1993 

(approval  date  February  1994) 

X.161  Definition  of  Customer  Network  Management  Services  for  Public  Data  Networks,  Draft,  1993 

(approval  date  November  1994) 

X.l 62  Definition  of  Management  Infotmaioo  for  the  Customer  Network  Management  Services  for  Public 

Data  Networks,  Draft,  1993  (approval  date  November  1994) 

PUBLIC  DATA  NETWORKS:  Administrative  Arrangements 

X.180  Administrative  Arrangements  for  International  Closed  User  Groups  (CUGs),  1988 

X.18I  Administrative  Arrangements  for  the  Provision  of  International  Permanent  Virtual  Circuits  (PVCs), 

1988 

OPEN  SYSTEMS  INTERCONNECTION:  Model  and  Notation 

X.200  Information  Technology  -  Open  Systems  Inercoonectioo  -  Reference  Model:  Basic  Reference  Model 

(ISO/IEC  7498),  1988  (approval  data  for  Revision  1  November  1994) 

X.207  Information  Technology  •  Open  Systems  Inercoonection  •  Application  Layer  Structure  (ISO  9S4S) 

(TTU-TS  ballot  ended  November  1993) 

X.20S  Specification  of  Abstract  Syntax  Notation  One  (ASN.l)  (ISO  8824),  1988  (see  X.680) 

X.209  Specification  of  Bisk  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.l)  (ISO  8823),  1988 

(see  X.690) 

X. 210:1988  OSI  Layer  Service  Definition  Convention*  (ISO  8309),  1988 

X. 210:1993  Conventions  for  Definitions  of  OSI  Services  (ISO  1073I),  Draft,  1993  (revision  submitted  for  ITU- 

TS  ballot  that  eoded  November  1993) 

X.211  Physical  Service  Definition  of  OSI  for  COTT  Applications  (ISO  L0022X  1988 

X.2I2  Data  link  Service  Definition  of  OSI  for  COTT  Applications  (ISO  8886),  1988 
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X.213  Network  Service  Definition  of  OSI  for  CCTIT  Applications  (IK)  8348).  1992  (approval  dale  for 

common  text  with  ISQ/IEC  November  1994) 

X.214  Transport  Service  Definition  of  OSI  for  CCITT  Applications  (ISO  8072),  1988  (revisioo  submitted 

for  mJ-TS  ballot  that  ended  November  1993) 

X.213  Session  Service  Definition  for  OSI  for  CCITT  Applications  (ISO  8826),  1988  (approval  dale  for 

common  text  with  ISQ/IEC  February  1994) 

X.216  Presentation  Service  Definition  for  OSI  for  CCITT  Applications  (ISO  8822),  1988  (approval  dale 

for  common  text  with  ISQ/IEC  February  1994) 

X.217  Service  Definition  for  the  Association  Control  Service  Element  (ISO  8649),  1992  (approval  dale  for 

common  text  with  ISQ/IEC  November  1994) 

X.218  Rev  1  Reliable  Transfer  Model  and  Service  Definition  (ISO  9066-1),  1993 

X.219  Remote  Operations:  Model,  Notation  and  Service  Definition  (ISO  9072-1),  1988  (see  X.880  and 

X.881) 

OPEN  SYSTEMS  INTERCONNECTION:  Connection-mode  Protocol  Specifications 
X.220  Rev  1  Use  of  X.200-Seriei  Protocols  in  CCITT  Applications,  1993 

X.222  Use  of  X.25  LAPB  to  Provide  the  OSI  Connection-mode  Data  Link  Service  (Appendix  m  of  X.212), 

1988  (approval  date  for  common  text  with  ISQ/IEC  November  1994) 

X.223  Use  of  X.23  to  Provide  the  OSI  Connection-mode  Network  Service  for  CCITT  Applications 

(ISO  8878],  1988  (revisioo  submitted  for  ITU-TS  ballot  that  ended  November  1993) 

X.224  Protocol  for  Providing  the  OSI  Connection-mode  Transport  Service  (ISO  8073),  1988  (revision 

submitted  for  ITU-TS  ballot  that  ended  November  1993) 

X.223  Session  Protocol  Specification  for  OSI  for  CCITT  Applications  (ISO  8327),  1988  (approval  dale  for 

common  text  with  ISQ/IEC  February  1994) 

X.226  Presentation  Protocol  Specification  for  OSI  for  CCITT  Application  (ISO  8823),  1988  (approval  dale 

for  common  text  with  ISO/IEC  February  1994) 

X.227  Protocol  Specification  for  the  Association  Control  Service  Element  (ISO  8650),  1992  (approval 

dale  for  common  text  with  ISOAEC  November  1994) 

X.228  Reliable  Transfer:  Protocol  Specification  (ISO  9066-2).  1988 

X.229  Remote  Operations:  Protocol  Specification  (ISO  9072-2).  1988  (see  X.882) 

OPEN  SYSTEMS  INTERCONNECTION:  Connection  less-mode  Protocol  Specifications 

X.233  Information  Technology  -  Open  Systems  Interconnection  -  Protocol  for  Providing  Connectionless- 

Mode  Network  Service  (ISO  8473-1),  Draft.  1993  (submitted  for  ITU-TS  ballot  that  ended  November 

1993) 

X.234  Information  Technology  -  Open  Systems  Interconnection  •  Protocol  for  Providing  the  OSI 

Connectionless-Mode  Transport  Service  (ISO  8602),  Draft.  1993  (approval  dale  February  1994) 
X.233  Information  Technology  •  Open  Systems  Interconnection  -  Connectionless-Mode  Session 

Protocol:  Protocol  Specification  (ISO  9348),  Draft,  1993  (approval  dale  November  1994) 

X.236  Information  Technology  -  Open  Systems  Interconnection  -  Connectionless-Mode  Presentation 

Protocol:  Protocol  Specification  (ISO  9576),  Draft,  1993  (approval  dale  February  1994) 

X.237  Information  Technology  -  Open  Systems  Interconnection  •  Connectionless-Mode  Protocol 

Specification  for  the  Association  Control  Service  Element  (ISO  10035),  1992 
OPEN  SYSTEMS  INTERCONNECTION:  Miscellaneous 

X.244  >  Procedure  for  the  Exchange  of  Protocol  Identification  During  Virtual  Call  Establishment  on  Packet 

Switched  Public  Data  Networks,  1988 

X.245  Information  Technology  •  Open  Systems  Interconnection  -  Connection-Mode  Session  Protocol: 

PICS  Proforma  (ISO  8327-2),  Draft.  1993  (approval  dale  November  1994) 

X.246  Information  Technology  -  Open  Systems  Interconnection  -  Connection-Mode  Presentation 

Protocol:  PICS  Proforma  (ISO  8823-2),  Draft,  1993  (approval  date  February  1994) 

X.247  Information  Technology  •  Open  Systems  Interconnection  •  Connection-Mode  Protocol 

Specification  for  the  Association  Control  Service  Element:  PICS  Proforma  (ISO  8650-2).  'Draft, 
1993  (approval  date  February  1994) 

X.248  Reliable  Transfer  Service  Element  -  PICS  Proforma,  1992 

X.249  Remote  Operations  Service  Element  -  PICS  Proforma,  1992 

X.233  Information  Technology  •  Open  Systems  Interconnection  -  Connectionless-Mode  Session 

Protocol:  PICS  Proforma  (ISO  9348-2),  Draft,  1993  (approval  date  February  1994) 

X.236  Information  Technology  -  Open  Systems  Interconnection  -  Connectionless-Mode  Presentation 

Protocol:  PICS  Proforma  (ISO  9576-2),  Draft,  1993  (approval  date  February  1994) 

X.257  Information  Technology  •  Open  Systems  Interconnection  •  Connectionless-Mode  ACSE  Protocol: 

PICS  Proforma  (ISO  10035-2),  Draft,  1993  (approval  dale  February  1994) 

OPEN  SYSTEMS  INTERCONNECTION:  Protocol  Identification 

X.263  Network  Protocol  Identification  Mechanism  (TR  9577),  Draft,  1993  (approval  dale  November 

1994) 

X.264  Transport  Protocol  Identification  Mechanism  (ISO  11570),  Draft,  1993  (mbmittad  for  ITU-TS 

ballot  that  ended  November  1993) 
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OPEN  SYSTEMS  INTERCONNECTION:  Security  Protocol! 

X.273  Information  Technology  -  Open  Systems  Interconnection  -  Network  Layer  Security  Protocol 

(ISO  11577),  Draft,  1993  (approval  target  February  1994) 

X.274  Information  Technology  •  Open  Systems  Interconnection  -  Transport  Layer  Security  Protocol 

(ISO  10736),  Draft,  1993  (approval  target  February  1994) 

OPEN  SYSTEMS  INTERCONNECTION:  Layer  Managed  Objects 

X.281  Elements  of  Management  Information  Related  to  the  OSI  Physical  Layer  ,lSO  13642),  Draft,  1993 

(approval  target  June  1995) 

X.282  Elements  of  Management  Information  Related  to  the  OSI  Data  Link  Layer  (ISO  10742),  Draft,  1993 

(approval  target  February  1994) 

X.283  Elements  of  Management  Information  Related  to  the  OSI  Network  Layer  (ISO  10733)  (submitted  for 

ITU-TS  ballot  that  ended  November  1993) 

X.284  Elements  of  Management  Information  Related  to  the  OSI  Transport  Layer  (ISO  10737),  Draft,  1993 

(approval  target  February  1994) 

X.290  OSI  Conformance  Testing  Methodology  and  Framework  for  Protocol  Recommendations  for  CdTl 

Applications:  General  Concepts  (DIS  9646-1),  1992  (approval  target  for  revision  and  common  text 
with  ISG/IEC  November  1994) 

X.291  OSI  Conformance  Testing  Methodology  and  Framework  for  Protocol  Recommendations  far  CC3TT 

Applications:  Abstract  Test  Suite  Specifications  (ISO  9646-2),  1992  (approval  target  for  revision 
and  common  text  with  ISO/IEC  November  1994) 

X.292  OSI  Cboformance  Testing  Methodology  and  Framework  for  Protocol  Recommendations  for  CCTTT 

Applications:  TTCN  (ISO  9646-3),  1992  (approval  target  for  revision  and  common  text  with 
ISO/IEC  November  1994) 

X.293  OSI  Conformance  Testing  Methodology  and  Framework  for  Protocol  Recommendations  for  CCTTT 

Applications:  Test  Realization  (ISO  9646-4),  1992  (approval  target  for  revision  and  common  text 
with  ISO/IEC  November  1994) 

X.294  OSI  Conformance  Testing  Methodology  and  Framework  for  Protocol  Recommendations  for  Cul'i 

Applications:  Requirements  on  Test  Labsoratories  and  Clients  for  Conformance  Assessment 
Process  (ISO  9646-5),  1992  (approval  target  for  revision  and  common  text  with  ISO/IEC  November 
1994) 

X.295  Information  Technology  -  Open  Systems  Interconnection  -  Conformance  Testing  Methodology  and 

Framework  •  Protocol  Profile  Test  Specification  (ISO  9646-6),  Draft,  1993  (approval  target 
November  1994) 

X.296  Information  Technology  •  Open  Systems  Interconnection  -  Conformance  Testing  Methodology  and 

Framework  -  Implementation  Conformance  Statements  (ISO  9646-7),  Draft,  1993  (approval  target 
November  1994) 

INTERWORKING  BETWEEN  NETWORKS:  General 

X.300  General  Principles  and  Arrangements  for  Interworking  Between  Public  Data  Networks,  and  Between 

Public  Data  Networks  and  Other  Public  Networks,  1988 

X.301  Rev  1  Description  of  the  General  Arrangement  for  Call  Control  Within  a  Subnetwork  and  Between 

Subnetworks  for  the  Provision  of  Data  Transmission  Services,  1993 

X.302  Description  of  the  General  Arrangement  for  Internal  Network  Utilities  Within  a  Subnetwork  and 

Immediate  Utilities  Between  Subnetworks  for  the  Provision  of  Data  Transmission  Services,  1988 

X.305  Functionalities  of  Subnetworks  Relating  to  the  Support  of  the  OSI  Connection-Mode  Network 

Service,  1988 

X.320  General  Arrangements  for  Interworking  Between  ISDNs  for  the  Provision  of  Data  Transmission 

Services,  1988  (approval  target  of  revision  June  1995) 

X. 321/1.540  General  Arrangements  for  Interworking  Between  Circuit  Switched  Public  Data  Networks  (CSPDNs) 

and  ISDNs  for  the  Provision  of  Data  Transmission  Services,  1988  (approval  target  of  revision 
June  1995) 

X.322  General  Arrangements  for  Interworking  Between  Packet  Switched  Public  Data  Networks  (PSPDNs) 

and  CSPDNs  for  the  Provision  of  Data  Transmission  Services,  1988 

X.323  Genera]  Arrangements  for  Interworking  Between  PSPDNs,  1988 

X.324  General  Arrangements  for  Interworking  Between  PSPDNs  and  Public  Mobile  Systems  for  the 

Provision  of  Data  Transmission  Services,  1988 

X.325  General  Arrangements  tor  Interworking  Between  PSPDNs  and  ISDNs  for  the  Provision  of  Data 

Transmission  Services,  1988  (approval  target  of  revision  June  1995) 

X.326  General  Arrangements  for  Interworking  Between  PSPDNs  and  Common  Channel  Signalling 

Network  (CCSN),  1988 

X.327  General  Arrangements  for  Interworking  Between  PSPDNs  and  Private  Data  Networks  for  the 

Provision  of  Data  Transmission  Services,  1988  (ITU-TS  balloting  of  revision  ended 
November  1993) 

XJ40  Rev  1  General  Arrangements  for  Interworking  Between  PSPDNs  and  the  International  Telex  Network, 

1993 

X.3fi  General  Arrangements  for  Interworking  Between  Frame  Relaying  Public  Data  Networks  and  ISDNs, 

Draft,  1993  (approval  target  November  1994) 
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X.350  General  Interworking  Requirements  to  be  Met  for  Data  Transmission  in  Intemational  Public  Mobile 

Satellite  Syatenu,  1988 

X.351  Special  Requirements  to  be  Met  for  Packet  Aaaembly/Diaataenibly  Facilities  (PAD*)  Located  at  or  in 

Association  with  Coast  Earth  Stations  in  the  Public  Mobile  Satellite  Service,  1988 
X.3S2  Interworking  Between  Packet  Switched  Public  Data  Networks  and  Public  Maritime  Mobile  Satellite 

Data  Transmission  Systems,  1988 

X.3S3  Routing  Principles  for  Interconnecting  Public  Maritime  Mobile  Satellite  Data  Transmission 

Systems  with  Public  Data  Networks,  1988 
INTERWORKING  BETWEEN  NETWORKS:  Management 

X.370  Arrangements  for  the  Transfer  of  Internetwork  Management  Information,  1988 

MESSAGE  HANDLING  SYSTEMS 

X.400/F.400  Rev  1  Message  Handling  Systems  (MHSs):  .  Message  Handling  System  and  Service  Overview 
(ISO  10021-1),  1993  (approval  target  for  common  text  with  ISO/IEC  November  1994) 

X.401  MHSs  -  Basic  Service  Elements  and  Optional  User  Facilities,  1984  (discontinued) 

X.402  MHSs  -  Overall  Architecture  (ISO  10021-2),  1992  (approval  target  for  common  text  with  ISO/IEC 

November  1994) 

X.403  MHSs  -  Conformance  Testing,  1988 

X.407  MHSs  -  Abstract  Service  Definition  Conventions  (ISO  10021-3),  1988  (approval  target  for  revision 

and  common  text  with  ISO/IEC  November  1994) 

X.408  MHSs  -  Encoded  Information-Type  Conversion  Rules,  1988 

X.409  MHSs  -  Presentation  Transfer  Syntax  and  Notation,  1984  (replaced  by  X.208  (ISO  8824  with  DAD 

1)  and  X.208  (ISO  8823  with  DAD  1))  (discontinued) 

X.410  MHSs  -  Remote  Operations  and  Reliable  Transfer  Server,  1984  [replaced  by  X.218  (ISO  9066-1), 

X.219  (ISO  9072-1),  X.228  (ISO  9066-2),  and  X.229  (ISO  9072-2)]  (discontinued) 

X.411  MHSs  -  Message  Transfer  System:  Abirtract  Service  Definition  and  Procedures  (ISO  10021-4),  1992 

(approval  target  for  common  text  with  ISO/IEC  November  1994) 

X.413  MHSs  -  Message  Store:  Abstract  Service  Definition  (ISO  10021-3),  1992  (approval  target  for 

common  text  with  ISO/IEC  November  1994) 

X.419  MHSs  -  Protocol  Specifications  (ISO  10021-6),  1992  (approval  target  for  common  text  with 

ISO/IEC  November  1994) 

X.420  MHSs  -  Interpersonal  Messaging  Sysem  (ISO  10021-7),  1992  (approval  target  for  common  text 

with  ISO/IEC  November  1994) 

X.421  COMFAX  Use  of  MHS,  Draft,  1993  (approval  target  Febroaiy  1994) 

X.433  Message  Handling  Syatenu:  Electronic  Data  Interchange  (EM)  Messaging  System,  1991  (fast-track 

balloting  in  ISO/IEC) 

X.440  Message  Handling  Systems:  Voice  Messaging  System,  1992 

X.480  Message  Handling  Systems  and  Directory  Services  Conformance  Testing,  1992 

X.481  MHSs  -  P2  Protocol:  PICS  Proforma,  1992 

X.482  MHSs  -  PI  Protocol:  PICS  Proforma,  1992 

X.483  MHSs  -  P3  Protocol:  PICS  Proforma,  1992 

X.484  MHSs  -  P7  Protocol:  PICS  Proforma,  1992 

X.483  MHSs  -  Voice  Messaging  System  PICS  Proforma,  1992 

X.4acc  Information  Technology  -  Communication  -  Message  Handling  System  (MHS):  Computer 

Conferencing,  Draft,  1993 

X.4ae  MHS  Management:  Access  Unit  Entity,  Draft,  1993  (approval  target  1993-1996) 

X.4agc  Information  Technology  -  Communication  -  Message  Handling  System  (MHS):  Group 

Communication,  Draft,  1993 

X.4cm  MHS  Management:  Configuration  Management  Function,  Draft.  1993  (approval  target  1993-1996) 

X.ep  Information  Technology  •  Message  Handling  Systems  -  PICS  Proforma  for  EDIMG,  Draft,  1993 

(approval  target  November  1994) 

X.4fm  MHS  Management:  Fauk  Management  Function,  Draft,  1993  (approval  target  1993-1996) 

X.4gm/X.inf  MHS  Management  Information  and  Functional  Overview,  Draft,  1993  (approval  target  1995- 

1996) 

X.4ma  MHS  Management  Accounting  Management,  Draft,  1993  (approval  target  November  1994) 

X.4me  MHS  Management:  Message  Store  Entity,  Draft,  1993  (approval  target  1993-1996) 

X.4mma  MHS  Management  Model  and  Architocgture,  Draft  1993  (approval  target  November  1994) 

X.4mo  MHS  Management:  MTA  Management  Draft,  1993  (approval  target  1995) 

X.4pm  MHS  Management:  Performance  Management  Function,  Draft,  1993  (approval  target  1993-1996) 

X.4sm  MHS  Management:  Security  Management  Draft  1993  (approval  target  June  1993) 

X.4ue  MHS  Management  User  Agent  Entity,  Draft,  1993  (approval  target  1995-1996) 

DIRECTORY 

X.500  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory:  Overview  of  Coocepts, 

Models,  and  Services  (ISO  9594-1),  1988  (revision  submitted  for  ITU-TS  ballot  that  ended 
November  1993) 
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X.SOl  Information  Technology  -  Open  Sytlemt  Interconnection  •  The  Directory:  The  Model* 

(ISO  9594-2),  1988  (revision  submitted  for  ITU-TS  ballot  that  ended  November  1993) 

X.509  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory:  Authentication 

Framework  (ISO  9594-8),  1988  (revision  submitted  for  ITU-TS  ballot  that  ended  November  1993) 
X.510  Overview  of  Sub-series  X.5 10  Recommendations 

X.511  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory:  Abstract  Service 

Definition  (ISO  9594-3),  1988  (revision  submitted  for  ITU-TS  ballot  that  ended  November  1993) 
X.518  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory:  Procedures  for 

Distributed  Operation  (ISO  9594-4),  1988  (revision  submitted  for  ITU-TS  ballot  that  ended 
November  1993) 

X.519  Information  Technology  -  Open  Systems  Interconnection  •  The  Directory:  Protocol  Specification 

(ISO  9594-5),  1988  (revision  submitted  for  ITU-TS  ballot  that  ended  November  1993) 

X.520  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory:  Selected  Attribute  Types 

(ISO  9594-6),  1988  (revision  submitted  for  ITU-TS  ballot  that  ended  November  1993) 

X.521  Information  Technology  •  Open  Systems  Interconnection  •  The  Directory:  Selected  Object  Classes 

(ISO  9594-7),  1988  (revision  submitted  for  ITU-TS  ballot  that  ended  November  1993) 

X.525  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory:  Replication 

(ISO  9594-9),  1988  (revision  submitted  for  ITU-TS  ballot  that  ended  November  1993) 

X.581  Directory  Access  Protocol  -  PICS  Proforma,  1992  (ISO  9594-10  being  fast-tracked) 

X.582  Directory  System  Protocol  -  PICS  Proforma,  1992  (ISO  9594-10  being  fast-tracked) 

OSI  NETWORKING  AND  SYSTEM  ASPECTS:  Networking 

X.610  Provision  and  Support  of  the  OSI  Connection-Mode  Network  Service,  1992 

X.612  Information  Technology  -  Provision  of  die  OSI  Connection-Mode  Network  Service  by  Packet  Mode 

Terminal  Equipment  Connected  to  an  ISDN,  1992 

X.613  Information  Technology  -  Use  of  X.25  Packet  Layer  Protocol  in  Conjunction  with  X.21/X.21  Ins  to 

Provide  the  OSI  Connection-Mode  Network  Service,  1992 

X.614  Information  Technology  -  Use  of  X.25  Packet  Layer  Protocol  in  Conjunction  with  X.21/X.21  bis  to 

Provide  the  OSI  Connection -Mode  Network  Service  over  the  Telephone  Network,  1992 
X.615  Information  Technology  •  Provision  of  the  OSI  Connection-Mode  Network  Service  over  Frame 

Relay.  1992 

X.620  Information  Technology  -  Provision  and  Support  of  the  OSI  Connection-Mode  Network  Service 

over  Frame  Relay,  1992 

X.622  Information  Technology  -  Use  of  X2S  Packet  Layer  Protocol  in  Conjunction  with  X.21/X.21  bis  to 

Provide  the  OSI  Connection-Mode  Network  Service  over  the  Telephone  Network.  1992 
X.623  Information  Technology  -  Use  of  X.25  Packet  Layer  Protocol  in  Conjunction  with  X.21/X.21  bis  to 

Provide  the  OSI  Connection-Mode  Network  Service  over  the  Telephone  Network.  1992 
OSI  NETWORKING  AND  SYSTEM  ASPECTS:  Naming,  Addressing,  and  Registration 
X.650  Information  Technology  -  Open  Systems  Innterconoection  -  Basic  Reference  Model:  Naming  and 

Addressing  (ISO  7498-3),  1992 

X.660  Information  Technology  -  Open  Systems  Inntercormcction  •  Procedures  for  the  Operation  of  OSI 

Registration  Authorities:  General  Procedures  (ISO  9834-1),  1992 
X.662  Information  Technology  •  Open  Systems  Innterconnection  •  Procedures  for  the  Operation  of  OSI 

Registration  Authorities:  Registration  of  Object  Identifier  Component  Values  for  Joint  ISO-CdTT 
Use  (ISO  9834-3),  Draft.  1993  (target  approval  November  1994) 

X.665  Information  Technology  -  Open  Systems  Innterconnection  -  Procedures  for  the  Operation  of  OSI 

Registration  Authorities:  Application  Processes  and  Applicaioo  Entitite  (ISO  9834-6),  1992 
OSI  NETWORKING  AND  8YSTEM  ASPECTS:  ASN.l 

X.680  Information  Technology  •  Open  Systems  Innterconnection  •  ASN.l:  Specification  of  Basic 

Notation,  Basic  ASN.l  (ISO  8824-1),  Draft,  1993  (approval  target  February  1994)  (aee  X.208) 
X.681  Information  Technology  -  Open  Systems  Innterconnection  -  ASN.l:  Information  Object 

Specification  (ISO  8824-2),  Draft,  1993  (approval  target  February  1994) 

X.682  Information  Technology  •  Open  Systems  Innterconnection  -  ASN.l:  Constraint  Specification 

(ISO  8824-3),  Draft,  1993  (approval  tvget  February  1994) 

X.683  Information  Technology  -  Open  Systems  Interconnection  -  ASN.l:  Parameterization  of  ASN.l 

Specifications  (ISO  8824-4),  Draft,  1993  (approval  target  February  1994) 

X.690  Information  Technology  -  Open  Systems  Innterconnection  -  Specification  of  ASN.l  Encoding 

Rules:  Basic  Encoding  Rules  (ISO  8825-1),  Draft,  1993  (approval  target  February  1994)  (aee 
X.209) 

X.691  Information  Technology  -  Open  Systems  Innterconnection  -  Specification  of  ASN.l  Encoding 

Rules:  Packet  Encoding  Rules  (ISO  8825-1),  Draft,  1993  (approval  target  June  1995) 

X.692  Information  Technology  -  Open  Systems  Innterconnection  •  Specification  of  ASN.l  Encoding 

Rules:  Distinguished  ad  Canonical  Encoding  Rules  (ISO  8825-3),  Draft,  1993  (approval  target 
February  1994) 
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061  MANAGEMENT 

X.700  Management  Framework  for  Open  Systems  Interconnection  (OSI)  for  CCTTT  Applications 

(ISO  7498-4).  1992 

X.701  Information  Technology  -  Open  Systems  ^interconnection  •  Systems  Management  Overview 

(ISO  10040),  1992 

X.702  Information  Technology  -  Open  Systems  Innlerconnection  •  Application  Context  for  Systems 

Management  for  Transaction  Processing  (ISO  11587),  Draft,  1993  (target  approval  June  1995) 
X.710  Common  Management  Information  Service  Definition  for  CCTTT  Applications  (ISO  9595),  1991 

X.71 1  Common  Management  Information  Protocol  Specification  for  CCTTT  Applications  (ISO  9596-1), 

1991 

X.712  Information  Technology  •  Open  Systems  Ionterconnection  -  Common  Management  Information 

Protocol:  PICS  Proforma  (ISO  9596-2),  1992 

X.720  Information  Technology  -  Open  Systems  Innlerconnection  -  Structure  of  Management  Information: 

Management  Information  Model  (ISO  10165-1),  1992 

X.721  Information  Technology  -  Opm  Systems  Innlerconnection  -  Structure  of  Management  Information: 

Definition  of  Management  Information  (ISO  10165-2),  1992  (approval  target  for  revision 
June  1995) 

X.722  Information  Technology  •  Open  Systems  Innlerconnection  -  Structure  of  Management  Information: 

Guidelines  for  the  Definition  of  Managed  Objects  (ISO  10165-4),  1992 
X.723  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of  Management  Information  - 

Generic  Management  Information  (ISO  1016S-S)  (ITU-TS  balloting  ended  November  1993) 

X.724  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of  Management  Information  - 

Requirements  and  Guidelines  for  Implementation  of  Conformance  Statement  Proformas  Associated 
with  Management  Information  (ISO  10165-6)  (ITU-TS  balloting  ended  November  1993) 

X.725  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of  Management  Information  • 

General  Relationship  Model  (ISO  10165-7),  Draft,  1993  (approval  target  June  1995) 

X.730  Information  Technology  •  Open  Systems  Interconnection  •  Systems  Management:  Object 

Management  Function  (ISO  10164-1),  1992  (approval  target  for  revisioo  November  1994) 

X.731  Information  Technology  -  Open  Systems  Interconnection  •  Systems  Management:  State 

Management  Function  ISO  10164-2),  1992  (approval  target  for  revision  November  1994) 

X.732  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management:  Attributes  for 

Representing  Relationships  (ISO  10164-3),  1992  (approval  target  for  revisioo  November  1994) 
X.733  Information  Technology  •  Open  Systems  Interconnection  -  Systems  Management:  Alarm 

Reporting  Function  (ISO  10164-4),  1992  (approval  target  for  revision  November  1994) 

X.734  Information  Technology  •  Open  Systems  Interconnection  -  Systems  Management:  Event  Report 

Management  Function  (ISO  10164-5),  1992  (approval  target  for  revision  November  1994) 

X.735  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management:  Log  Control 

Function  (ISO  10164-6),  1992  (approval  target  for  revision  November  1994) 

X.736  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management-  Security  Alarm 

Report  Function  (ISO  10164-7),  1992  (approval  target  for  revision  November  1994) 

X.737  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management  Confidence  and 

Diagnoiic  Test  Categories  (ISO  10164-14),  Draft,  1993  (approval  target  February  1994) 

X.738  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management  Summarization 

’’  Function  (ISO  10164-13)  (ITU-TS  balloting  ended  November  1993) 

X.739  Information  Technology  •  Open  Systems  Interconnection  -  Systems  Management  Metric  Objects 

and  Attributes  (ISO  10164-11)  (ITU-TS  balloting  ended  November  1993) 

X.740  Information  Technology  •  Open  Systems  Interconnection  -  Systems  Management  Security  Audit 

Trail  Function  (ISO  10164-8),  1992 

X.741  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management  Objects  and 

Attributes  for  Access  Control  (ISO  10164-9),  Draft,  1993  (approval  target  February  1994) 

X.742  Information  Technology  •  Open  Systems  Interconnection  -  Systems  Management:  Usage  Mr  hiring 

Function  (ISO  10164-10),  Draft,  1993  (approval  target  February  1994) 

X.743  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management:  Time 

Management  Function  (ISO  10164 -tm),  Draft,  1993  (approval  target  1998) 

X.744  Information  Technology  •  Open  Systems  Interconnection  •  Systems  Management:  Software 

Management  Function  (ISO  10164-sw),  Draft,  1993  (approval  target  1997) 

X.745  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management:  Test 

Management  Function  (ISO  10164-12)  (ITU-TS  balloting  ended  November  1993) 

X.746  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management:  Scheduling 

Function  (ISO  10164-15),  Draft,  1993  (approval  target  February  1994) 

X.747  Information  Technology  -  Open  Systams  Interconnection  -  Systems  Management:  General 

Relationship  Function  (ISO  10164-tm),  Draft,  1993  (approval  target  1997) 

X.748  Information  Technology  •  Open  Systems  Interconnection  •  Systems  Management:  Response  Tims 

Monitoring  Function  (ISO  10164-rtin),  Draft,  1993  (approval  target  1998) 
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X.749  Information  Technology  -  Open  Syetems  Interconnection  -  System*  Management:  Management 

Domnin  Management  Function  (ISO  10164-md),  Draft,  1993  (approval  target  1997) 

X.730  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management  Management 

Knowledge  Management  Function  (ISO  10164-16),  Draft,  1993  (approval  target  November  1994) 
X.7S1  Information  Technology  -  Open  Systems  Interconnection  -  Systems  Management:  Change  Over 

Function  (ISO  10164-co),  Draft,  1993  (approval  target  1997) 

X.732  Information  Technology  •  Open  System*  Interconnection  •  Systems  Management  Enhanced  Event 

Control  Function  (ISO  10164-ev),  Draft.  1993  (approval  target  1997) 

SECURITY 

X.800  Security  Architecture  for  Open  Systems  Interconnection  for  CCl  l  T  Applications  (ISO  7498-2), 

1991 

X.802  Information  Technology  -  Open  Systems  Interconnection  -  Lower  Layers  Security  Mode) 

(TR  13594),  Draft,  1993  (approval  target  November  1994) 

X.810  Information  Technology  -  Open  Systems  Interconnection  -  Security  Frameworks  in  Open  Systems: 

Security  Authentication  Frameworks  Overview  (ISO  18181-1),  Draft,  1993  (approval  target 
November  1994) 

X.811  Information  Technology  -  Open  Systems  Interconnection  -  Security  Frameworks  in  Open  Systems: 

Authentication  Framework  (ISO  18181-2),  Draft,  1993  (approval  target  February  1994) 

X.812  Information  Technology  -  Open  Systems  Interconnection  -  Security  Frameworks  in  Open  Systems: 

Access  Control  Framework  (ISO  18181-3),  Draft,  1993  (approval  target  November  1994) 

X.813  Information  Technology  -  Open  Systems  Interconnection  -  Security  Frameworks  in  Open  Systems: 

Non-Repudiation  Framework  (ISO  18181-4),  Draft,  1993  (approval  target  November  1994) 

X.814  Information  Technology  -  Open  Systems  Interconnection  -  Security  Framework*  in  Open  Systems: 

Confidentiality  Framework  (ISO  18181-5),  Draft,  1993  (approval  target  November  1994) 

X.815  Information  Technology  -  Open  Systems  Interconnection  -  Security  Frameworks  in  Open  Systems: 

Integrity  Framework  (ISO  18181-6),  Draft,  1993  (approval  target  November  1994) 

X.816  Information  Technology  -  Open  Systems  Interconnection  -  Security  Frameworks  in  Open  Systems: 

Security  Audit  Framework  (ISO  18181-7),  Draft,  1993  (approval  target  November  1994) 

X.830  Information  Technology  -  Open  Systems  Interconnection  •  Generic  Upper  Layers  Security  -  Security 

Eex change  Service  Element:  Overview,  Model  and  notation  (ISO  11586-1),  Draft,  1993  (approval 
target  November  1994) 

X.831  Information  Technology  -  Open  Systems  Interconnection  -  Generic  Upper  Layers  Security:  Security 

Eexchange  Service  Element  (SESE)  Service  Definition  (ISO  11586-2),  Draft.  1993  (approval  target 
November  1994) 

X.832  Information  Technology  -  Open  Systems  Interconnection  -  Generic  Upper  Layers  Security:  Security 

Eexchange  Service  Element  (SESE)  Protocol  Specification  (ISO  11586-3),  Draft.  1993  (approval 
target  November  1994) 

X.833  Information  Technology  •  Open  Systems  Interconnection  -  Generic  Upper  Layers  Security: 

Protecting  Transfe  Syntax  Specification  (ISO  11586-4),  Draft,  1993  (approval  target 
November  1994) 

X.834  Information  Technology  -  Open  Systems  Interconnection  -  Generic  Upper  Layers  Security:  Security 

Eexchange  Service  Element  (SESE)  PICS  Proforma  (ISO  11586-5).  I>aft,  1993  (approval  target 
November  1994) 

X.835  Information  Technology  -  Open  Systems  Intctconnectioo  -  Generic  Upper  Layers  Security:  Security 

Eexchange  Service  Element  (SESE)  Protecting  Transfer  Syntax  PICS  Proforma  (ISO  1 1 586-6 X  Draft, 
1993  (approval  target  November  1994) . 

COMMITMENT,  CONCURRENCY  AND  RECOVERY 

X.851  Information  Technology  -  Open  Systems  Interconnection  -  Service  Definition  of  CCR  Service 

Element.  Edition  2  (ISO  9804)  (submitted  for  ITU-TS  ballot  that  ended  November  1993) 

X.8S2  Information  Technology  •  Open  Systems  Interconnection  -  CCR  Service  Element:  Protocol 

SpeciTcatioo  (ISO  9805-1)  (submitted  for  ITU-TS  ballot  that  ended  November  1993) 

X.853  Infonuatioo  Technology  -  Open  Systems  Ioterconnectioo  •  CCR  Service  Element:  PICS  Proforma, 

Edition  2  (ISO  9805-2 X  Draft,  1993  (approval  target  February  1994) 

TRANSACTION  PROCESSING 

X.S60  Distributed  Transaction  Perocessing:  Model  (ISO  10026-1),  1992 

X.861  Distributed  Transaction  Perocessing:  Service  (ISO  10026-2),  1992 

X.862  Distributed  Transaction  Perocessing:  Protocol  Specification  (ISO  10026-3)  (submitted  for  ITU-TS 

ballot  that  ended  November  1993) 

X.863  Information  Technology  •  Open  Systems  Ioterconnectioo  •  Distributed  Transaction  Perocessing: 

PICS  Proforma  (ISO  10026-4),  Draft,  1993  (approval  target  February  1994) 

REMOTE  OPERATIONS 

X.880  Information  Technology  -  Remote  Operation*  (RO),  Part  1:  Model,  1993  (CD  13712-1),  Draft, 

1993  (approval  target  February  1994) 

X.881  Information  Technology  -  Remote  Operations  (ROX  Part  2:  Service,  1993  (CD  13712-2),  Draft, 

1993  (approval  target  February  1994) 
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X.882  Information  Tecteology  •  Remota  OpwatRms  (BO),  Part  3:  Protocol.  1993  (CD  13712-3),  Draft. 

1993  (approval  large!  February  1994) 

X.8S3  Information  Technology  •  Remote  Operation  (BOX  Part  4:  PICS  Proforma.  1993  (CD  13712-4), 

Draft,  1993  (approval  target  February  1994) 

OPEN  DISTRIBUTED  PROCESSING 

X.901  Information  Technology  -  Baaic  Reference  Model  for  Open  Distributed  PWceaaing:  Overview  and 

Guide  to  Uae  (ISO  10746-1),  Draft,  1993  (approval  target  1996) 

X.902  Information  Technology  •  Baaic  Reference  Model  for  Open  Distributed  Processing:  Descriptive 

Model  (ISO  10746-2),  Draft,  1993  (approval  target  June  1995) 

X.903  Information  Technology  -  Basic  Reference  Model  for  Open  Distributed  Processing:  Prescriptive 

Model  (ISO  10746-3).  Draft,  1993  (approval  target  June  1995) 

X.904  Information  Technology  •  Basic  Reference  Model  for  Open  Distributed  Processing:  Architectural 

Semantics  (ISO  10746-4),  Draft,  1993  (approval  target  1996) 

X.tr  Information  Technology  -  Basic  Reference  Model  for  Open  Distributed  Processing:  Uae  of  Formal 

Description  Technique  for  ODP,  Draft,  1993  (approval  target  1996) 

X.trader  Information  Technology  -  Basic  Reference  Model  for  Open  Distributed  Processing:  ODP  Trader, 

Draft,  1993  (approval  target  1996) 
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Specification  and  Description  Language  (SDL) 

Criteria  for  the  Uae  and  Applicability  of  Formal  Description  Techniques 

Messages  Sequence  Chans 

High  Level  Language  (CHILL)  [DIS  9496.2] 

Introduction  to  the  Man-Machine  Language  (MML) 

The  Meta-language  for  Describing  MML  Syntax  and  Dialogue  Procedures 
Introduction  to  Syntax  and  Dialogue  Procedures  (MML) 

Basic  Format  Layout  (MML) 

The  Character  Set  and  Basic  Elements  (MML) 

Input  (Command)  Language  Syntax  Specification  (MML) 

Output  Language  Syntax  Specification  (MML) 

Man-Machine  Dialogue  Procedures  (Mitt.) 

Introduction  to  the  Extended  MML  for  Visual  Display  Terminals 
Capabilities  of  Visual  Disptay’Terminals  (VDTs) 

Man-Machine  Interaction 

Introduction  to  the  Specification  of  the  Man-Machine  Interface 

Methodology  for  the  Specification  of  die  Man-Machine  Interface  -  General  Working  Procedures 
Methodology  for  the  Specification  of  the  Man-Machine  Interface  -  Tools  and  Methods 
Glossary  of  Terms  (MML) 

Data-oriented  Human-Machine  Interface  Specification  Techniques.  Part  1:  Introduction 
Data-oriented  Human-Machine  Interface  Specification  Techniques,  Part  2:  Scope,  Approach  and 
Reference  Model 

Structure  and  Format  of  Quality  Manuals  for  Telecommunication  Software 
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ORGANIZATIONS  FOR  STANDARDIZATION1 


1.  INTRODUCTION 

This  appendix  provides  as  overview  of  NATO  organizations  and  other  bodies  with  responsibility  for 
ifarlatdiialion  in  the  fields  of  communications  and  information  systems.  Eventually,  this  appendix  is  intended  lobe 
expanded  to  show  specific  responsibilities  at  each  of  the  standards  bodies.  Where  appropriate,  the  charts  sbow  the 
dan  of  STANAGs  or  other  standards  maintained  by  each  organization.  The  emphasis  in  this  appendix  is  on 


2.  NATO  STANDARDS  BODIES 

Figare  F-l  (fokJont)  identifies  the  NATO  bodies  with  responsibility  for  standardization  in  cnmmnniratioas 
and  information  systems.  The  chart  only  shows  the  NATO  bodies  for  which  staff  support  is  provided  by  the  NATO 
Headquarters'  staffs,  with  the  exception  of  those  associated  with  the  NATO  Communications  and  Information 
Systems  Organization  (NACISO).  Operational  requirements  are  the  responsibility  of  the  Military  Cownrittee, 
primarily  through  the  Military  Agency  for  Standardization  (MAS).  Procedure!  standards  me  the  nssponsMMty  of  the 
Allied  Data  Systems  Interoperability  Agency  (ADS  LA),  which  reports  to  the  Military  Committee  throngh  the 
NACISO.  Technical  standards  are  the  responsfoility  of  the  Tri-Service  Group  on  Communirariom  and  Electronics 
(TSGCE). 

Many  groups  in  NATO  produce  standards.  A  substantial  part  of  die  woric  takes  place  within  the  stractnre  of 
the  Conference  of  National  Armaments  Directors  (CNAD),  and  is  mainly  concerned  with  material  standardization. 
The  Military  Agency  for  Standardization  (MAS)  is  exclusively  concerned  with  standardization,  primarily  in  the 
operational  field.  Specific  topics  are  also  dealt  with  by  other  groups  under  the  Military  Committee. 

In  1983  the  North  Atlantic  Council  decided  to  establish  a  NATO  Standardization  Group  (NSG)  composed  of 
national  representatives  from  both  the  operational  and  materiel-oriented  sides  of  defence  departments,  and 
representatives  from  the  Mqjor  NATO  Commands  (MNCs),  the  International  Staff  (IS),  the  International  Military 
Staff  (IMS)  and  the  MAS.  The  purpose  of  the  Group  is  to  provide  a  multi-national  forum  for  the  harmonirarion  of 
national  views  and  the  pursuit  of  NATO  standardization  activities.  The  Group  is  responsible  to  the  Conncil  for 
obtaining  national  and  staff  inputs  with  a  view  to  the  preparation  of  a  composite  NATO  Standardization  Programme 
(NSP)  to  be  submitted  to  the  NATO  Standardization  Tasking  Authorities,  after  approval  by  the  Council,  for 

2.1  NATO  Technical  Standards  Bodies 

TSGCE  has  created  a  number  of  subgroups  (SGs)  and  Project  Groups  (PGs)  to  develop  and  maintain 
technical  standards  for  NATO.  The  subgroups  and  selected  working  groups  (WGs)  arc3 

•  SG4  on  Navigation  and  Position  Hading 

•  SG5  on  Identification;  seeks  to  enhance  the  interoperability  of  current  identification  equipment  and  to 
ensure  the  standardization,  where  necessary,  to  the  NATO  Identification  System  (NIS) 

WG4  on  Question  and  Answer  (QAA)  System  Interoperability;  dedicated  to  Mark  X/Mark  XII 
issues,  but  win  consider  issues  affecting  the  optimum  implementation  of  the  NATO  QAA 
WGS  on  Transition  to  the  NIS  QAA 
WG6  on  Data  Processing 

•  SG9  on  Data  Distribution;  focuses  on  the  development  of  data  communications  protocols,  specifically 
for  the  NATO  OSI  Reference  Model 

WG4  on  Data  Links 
WGS  on  Profiles 
WG6  on  Pm-Layer  Isstr* 

Ad  Hoc  Working  Group  (AHWG)  on  Security 


1  Appendix  review!  February  1994  baaed  on  informal  comirbutione;  Guide  to  IT  Standard!  Molten  ami  Their  Standards 
(Ref.  TA  1991);  end  P1003.0  [Ref.  IEEE  1992). 

2  The  North  Aimak  Treaty  Organization-Facts  and  Figures  [NATO  1989). 

2  NATO  Bodies  in  the  Fields  of  Communications  and  Information  Systems  [NACISC  1918]  end  Directory-U.S. 
Ford  chants  in  the  International  C3  Font  [USMCEB  1989). 
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AHWG  oo  Integrated  Service*  Digital  Network  (ISDN) 

PG3  oo  Multinational  Information  Distribution  System  (MIDS) 

•  SG11  aa  Tactical  Commnnicatioos 

WG1  oo  Tactical  Area  Communications;  seeks  cooperation  among  the  NATO  nations  in  the 
development  mat  procurement  of  tactical  area  ronwnunirartons  for  national  forces 
WG8  on  Satellite  Communications  (SATCOM)  Systems;  seeks  SATCOM  interoperability 
between  NATO  and  national  military  SATCOM  systems 

PG6  on  Tactical  Communications  Systems  for  the  Land  Combat  Zone-Post  2000;  seeks, 
dmngb  a  coordinated  program,  tactical  communications  systems  designed  to  common  standards 

•  SG12  on  Information  Systems 

WG2  on  Data  Processing  and  Management 

AHWG  on  Army  Tactical  Command  and  Control  Information  System  (A7CCIS)  (convened  in 
conjunction  with  the  meetings  of  the  Technical  Subgroup  of  the  ATCCIS  Permanent  Working 
Onup). 

There  are  still  two  Project  Groups  reporting  directly  to  the  TSGCE: 

•  PG7  on  Battlefield  Information  and  Exploitation  Systems  (BICES) 

•  Special  Working  Group  (SWG)  on  Ada  Programming  Support  Environment  (APSE),  formed  by  10 
nations  in  1987  to  provide  an  environment  in  which  tools  can  work  together  effectively  to  support 
infonnatioo  systems  projects  for  the  total  development  life  cycle. 

Liaison  among  these  bodies  (c.g.«  PG6  and  SG9)  is  normally  at  the  Secretary  level.  Plans  are  coordinated  in  annual 
meetings  of  the  Secretaries  and  Action  Officers  of  the  Allied  Tactical  Communications  Agency  (ATCA),  the  Allied 
Naval  Communications  Agency  (ANCA),  the  Allied  Communications  and  Computer  Security  Agency  (ACCSA), 
and  the  cotnmarkations  subordinate  groups  of  TSGCE.4 

To  a  limited  degree,  technical  standards  are  also  being  addressed  in  the  NATO  Industrial  Advisory  Group 
(NIAG),  specifically  in  SG6  on  Compatibility  of  Naval  Data  Handling  Equipment  NIAG  SG6  is  making 
r  on  standards  to  be  used  in  shipboard  combat  systems  for  data  distribution,  such  as  the  Network 

hutependent  Interface  (NDF). 

Table  F-l  and  Figure  F-2  highlight  the  relationships  among  the  NATO  standards  bodies  whose 
responsftiMtiea  win  be  discussed  in  a  chart  that  follows.  To  clarify  the  relationships  among  the  organizations  and  to 
emphasise  those  bodies  concerned  wife  technical  standards,  some  of  the  NATO  bodies  have  been  left  oat  and  most  of 
the  names  have  been  replaced  with  acronyms.  Table  F-l  provides  the  definitions  of  the  acronyms  for  Figure  F-2. 

2.2  NATO  OSI  Standards  Bodies 

TSGCE  SG9  has  responsibility  for  the  NATO  OSI  Reference  Model  and  developing  OSI  STANAGs.  SG9 
also  maintains  the  NTIS  Transition  Strategy  [Purton  1987]  that  contains  intercept  recommendations. 

TSGCE  SG9  meets  biannually,  usually  in  March  and  October.  Beginning  in  1990,  SG9  will  meet 
approximately  6  to  8  weeks  after  the  fall  meetings  of  WG1  and  WG2,  to  allow  time  for  the  nations  to  coordinate 
positions  an  issues  developed  by  the  working  groups.  Thus,  the  next  meeting  of  S09  is  December  1990,  while 
WG1  and  WG2  will  meet  in  October  1990.  AHWGs  meet  approximately  quarterly. 

2.3  Standards  Responsibilities  of  Selected  NATO  Bodies 

Table  F-2  la  an  incomplete  first  draft  of  an  effort  to  identify  the  specific  responsibilities  of  NATO 
organizations  for  technical  stwdards.  Eventually,  this  nd  similar  tables  for  other  groups  of  standards  bodies  will  be 
analyzed  to  identify  overlaps  as  well  as  possible  gaps  in  the  standards  coverage.  The  following  describes  the  areas  of 
responsibilities  for  key  NATO  standards  bodies  [Ref.  N1PD 1993]: 

•  The  North  Atlantic  Council  (NAQ  and  Defence  Planting  Committee  (DPC)  promulgate  guidance  that 
embraces  interoperability,  interdependency,  md  interfaces  related  to  infotmatcin  exchange  in  NATO. 

•  The  NATO  Standardization  Group  (NSG),  directly  repoosible  to  the  NAC,  is  an  independent  body 
established  to  review  the  activities  of  all  NATO  bodies  involved  in  the  field  of  standardization,  to 
inciude  information  system  interoperability. 

•  The  Military  Committee  (MC)  is  repoosible  for  the  infrastructure-funded  military  subset  of  COS*, 
which  includes  support  for  the  MC  itself  at  NATO  hmrtqnsiratm,  the  Major  NATO  Commmanders 
(MNCs),  and  the  data  interfaces  between  the  various  systems  of  NATO  and  the  nations.  The  MC  has 
relinquished  it*  anthority  to  the  NACISC  to  provide  the  focus  for  communication  and  information 
system  (CIS)  interoperability  and  standardization  for  common-funded  systems. 


4  Wetting  RtlmUmthipt  (Ref.  NACISC  1989c]. 
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•  The  task  of  the  Military  Agency  for  Standardization  (MAS)  is  to  foster  military  standardization  within 
the  policy  established  by  the  MC  with  the  aim  of  enabling  the  NATO  forces  to  operate  effectively 
together.  The  MAS  is  responsible  for  the  NATO-wide  coordiantion  and  validation  of  tactical  IERs  and 
die  development  and  maintenance  of  operational  interoperability  standards.  The  MAS  initiates, 
promulgates,  and  maintains  STANAGs  and  Allied  publications. 

•  Allied  Tactical  Communications  Agency  (ATCA)  and  Allied  Naval  Communications  Agency  (ANCA) 
are  reponsible  to  the  MC  for  development  of  military  telecommunications  policy,  conoenpts,  plans, 
requirements,  and  procedures  to  ensure  an  effective  telecommunications  capability  for  tactical  land 
and/or  air  operations  (ATCA)  and  maritime  operations  (ANCA). 

•  Allied  Communications  and  Computer  Security  Agency  (ACCS A)  is  responsible  for  satisfying  peace- 
and  waitime-NATO  and  NATO-related  national  requirements  concerning  communications  security  and 
computer  security  matters. 

•  ARFAis  responsible  for  satsifying  peace-  and  waitime-NATO  and  national  radio  frequency 
reqaukements. 

•  NATO  Communications  and  Information  Systems  Committee  (NACISC)  provides  the  focus  for  CIS 
interoperability  and  standardisation  for  common  funded  systems.  It  is  tasked  iwth  specifying  the 
procedures  regarding  the  form  in  which  information  is  transferred,  standard  reporting  language,  and 
operational  procedures  appropriate  to  NATO  CCISs  and  associated  data  links. 

•  NATO  Communications  and  Information  Systems  Agency  (NACISA)  provides  central  technical 
planning  and  designs  th*  system  engineering  and  ranfigiitatiwi  management  for  NATO  fiSs  It  also 
provides  guidance  on  the  implementation  of  standards  and  their  application  in  national  systems. 

•  The  Communications  Systems  Working  Group  (CSWG— WG1)  and  the  Information  Systems 
Working  Group  (ISWG — WG2)  are  subordinate  bodies  of  the  NACISC,  responsible  for  NATO 
procedural  interoperability  standards  with  respect  to  communications  other  than  tactical  data  links 
(CSWG)  and  the  formulation  of  plicy  issues  with  special  consideration  for  interoperability 
requhements  (ISWG). 

•  The  Allied  Data  Systems  Interoperability  Agency  (ADSIA)  is  a  multinational  military  CIS  agency 
reponsible  to  the  NACISC  principally  for  coordinating  the  overall  development  and  configuration 
management  of  NATO  common  interoperability  standards,  except  those  under  the  purview  of  the 
CSWG. 

•  The  Conference  of  National  Armaments  Directors  (CNAD)  acts  under  direct  authority  of  the  NAC  and 
advise  the  NAC  on  matters  pertaining  to  the  development  and  procurement  of  defense  equipment  for 
NAT  forces  and  connected  problems.  In  the  field  of  OS  interoperability,  the  CNAD  is  primarily 
responsible  far  NATO  technical  interopeability  standards. 

•  Tri-Service  Group  on  Communications  and  Electronics  (TSGCE)  actively  promotes  and  enables 
collaboration  among  nations  of  the  Alliance  on  projects  to  develop,  test,  produce,  and  procure 
common  equipment  and  systems  in  order  to  minimize  cost  and  ensure  full  interoperability;  and  to 
develop  and  perform  configuration  management  of  technical  standards  in  Oder  to  promote  greater 
interoperability  in  NATO  and  national  systems. 

•  Three  armaments  groups  subordinate  to  the  CNAD  promote  cooperation  in  developing  and  producing 
weapon  systems  and  equipment:  NATO  Army  Annaaments  Group  (NAAG),  NATO  Air  Force 
Armaaroents  Group  (NAAFG),  and  NATO  Navy  Armaments  Group  (NNAG). 

•  The  NATO  Air  Defence  Committe  (NADC)  comprises  Air  Defence  Representatives  (ADREPs)  to 
provide  a  form  for  n  exchange  of  views  on  the  continuing  development  of  the  air  defense  program. 
Advice  is  provided  to  the  NADC  from  the  Panel  on  Air  Defense  Philosophy  (PADP),  wbcich 
addresses  possible  consequences  for  capabilities  and  proposals,  and  the  Panel  on  Air  Defence  Weapons, 
which  assists  in  the  development  of  a  coherent  air  defense  system  and  identifies  opportunities  far  and 
participates  in  collaboration  in  air  defhese  weapons  research,  development,  and  production. 

•  The  NATO  Air  Command  and  Control  Agency  (NACMA)  is  responsible  for  the  Air  Command  and 
Control  System  (ACCS)  development.  The  parent  body  of  NACMA  is  the  NATO  ACCS 
Management  Organization  Board  of  Direction  (NACMO  BOD). 


Appendix  F 


F-5 

UNCLASSIFIED 


Standards  Organizations 


UNCLASSIFIED 


TaMa  F-1.  Acronyma  and  TMaa  of  Kay  NATO  Bodlaa  In  tfca  Raida  of 
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Acronym 

None 

me 

North  Atlantic  Count* 

N6Q 

NATO  Olonrtorrtitollnn  Group 

DPC 

utranoB  runrany  MniTnwv 

MC 

MMary  CommtttM 

AQARO 

AdMoory  Group  lor  Aoroopaoo  Roooarch  and  Doealopmont 

MAS 

MWaty  Agency  lor  Standardiaion 

MNCi 

Major  NATO  Commands 

ACE 

ASsd  Comrund  Europe 

CHAN 

AM  Channol  Consmnd 

LAMT 

AM  Command  ASande 

ATCA 

AMad  Tadcal  Communtcaions  Agency 

ANCA 

AAed  Nivel  CommuniceMons  Apsney 

ALLA 

AM  Long  Unaa  Agency 

ARFA 

AM  Radto  Frequency  Agency 

A0C8A 

AMad  fljrtffHlffHwif  *wH  Rwiyaf  BawBy  Ijny 

AD8IA 

AMad  Data  Systems  tnteroperabMty  AQsncy 

SECAN 

Communkedons  Security  end  Eveluedon  Agency 

DACAN 

DiaMbuSon  and  Aooounlng  Agency 

eusec 

Qiropaan  Security  and  CvMuallonCommllBC 
QimpeanDlatiMonarrtAowunMng  Agency 

IMS 

mtamaSonal  MMary  Staff 

aswv 

Communtesttons  end  (nfonnetton  Systems  DMsion 

NACISO 

NAiu  commurao  lions  sna  mronnsscmoysNmsLJVvnraxnBon 

NAOSC 

NATO  Oommunloellons  end  WofmeSon  Systran!  Oommttse 

CSWQ 

Communloaliona  Syalama  WotMng  Group 

NRSQ 

NATO  RaffonalzaHon  Subgroup 

SC8Q 

SaMSe  Oommuntealono  Subgroup 

KSWQ 

mrofmsson  oyrosms  vrosny  wxe 

AISO 

we  ffTpanamon  emgroup 

NACISA 

NATO  Conwnunlosions  end  IntofmeHon  8ydsns  Aysncy 

MCS-CQA 

Central  OpeeNny  AuSwdly 

CHAD 

Contefsncaof  NATO  Aimamonto  Dtraotom 

TSQCEE 

Trt-Sarrtoa  Group  on  Oommurtoadona  and  Baobonte  Equipment 

NAAQ 

NATO  Aimy  Armomants  Group 

NAFAQ 

NATO  Air  Force  Amnamsnts  Groty 

IMAQ 

NATO  Navy  Armaments  Qrs«e 

DRQ 

Oatanoa  Research  Group 

MAQ 

NATO  MuobW  Advteory  Group 

CEAC 

Committee  lor  Europeen  Alrapeoe  Oooeflneion 

NAOC 

! 

i 
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Table  F-2.  Reeponeiblllty  for  Standard#  In  NATO  Bodlaa 


NXTOOnaitWInn 

TMa 

CNN) 

Cort  at  Natl  Aimamanu  Dfeacton 

TBQCEE 

Tri-Sarv  Grot#  Camm-EtacOon  Eodpmart 

TaeMcal  Standards 

SOI 

TmUlmI  Ai—  ConnurtMUom 

STANAGa  4206-4214,4240,4290,4296,50006014 

SQ2 

Taalcal  Radto  EaNxnanl 

STANAQs  41 97-4205,4246-46,4286-92,4336-30.5020 

80S 

lAJtFwcttonal  Mo  DMribuHon 

804 

NiviQSSon  ind  Portion  pindny 

806 

■ j  -  »*■  » 

nnvcaon 

807  J 

! 

s 

1 

1 

80* 

Tactical  SATCOM  TarmkW 

STANAGa  4231-33, 4271 

800 

MaPRMMfcswdOMMton 

NATO  061  Standards,  STANAG42S0 

AHW&Saourty 

061  Sacurty 

NATO  061  SMndaida  (Annas  B) 

AHWG-OM 

061  NttWOffc  MMQMNrt 

NATO  061  SMndarda  (a-fl-,  Nat  Mond) 

AUAMjem 

M  IMUtuUn 

Magndad  Sarvfeaa  DigUi  Namwk 

ISON  Standards  tor  Opan  Systama 

WGl 

Lawar  4  Laysn  oi  fMawnoa  Modal 

STANAGa  42S1-&4, 4281-64 

WG2 

Uppar  3  Layara  oi  Hatannoa  Modal 

STANAGa  42S5-66, 4258-50, 428666 

41  ■*«*<  taaia 

Mray  mg  mnong  oymni 

STANAG4257 

WQ3 

Comm  SymfltNilwofk  bMNpMbHy 

waj  vor  Mtmnrw  nwpvm 

8010 

uN^pnc  ivormmi 

PQ2 

NATO  IdanWMdeo  By#  am 

PQ3 

MD6 

PGM 

Law  Coal  MS  lor  SI** 

PQ6 

MuNFuncdonal  InarlW  Sanaor  Aaaantdy 

poa 

Toe  Comm  Pool  2000-Und  Cofftmt 

PG7 

BICES 

POO 

Tactical  SpacUum  Mgnd  Sy*am 

OQN 

Cottfofinanoo  TtSing 

MAG 

NATO  kidJrtM  AdAaory  Omp 

80S 

Naal  Qala  Handho  EqdPawd 

FuneNonb  PpoSss 

NACBC 

NATO  Conan  and  fedo  Sya  ComnWas 

OwmigN  lor  Prooaduaal  Standards 

CSW3 

CoBwSymmWorting  Qrots> 

SWG 

WomMlion  Systems  Wortdng  Qfotg> 

M8Q 

Addp  brpiimsnttelon  Stmgrotp 

NACtSA 

NATO  Coaan  and  Into  Sya  Agancy 

MC&COA 

Cararal  Oparatog  AWhoifey 

1C 

MMary  CoiwiSm 

MS 

b*tmtebr«l  fefltory  8tf 

oocson 

Cornmnd,  Conbol  ««J  Comm  System 

STANAGa  50006006 

CMC 

Conan  and  fedo  SyatamaOMon 

sa 

SyOoni  MoroporsMy  Dnndt 

MAS 

MMwy  Agoncy  toe  SbndmtzSton 

OparaMonal  SMndarda  (STANAGa  10006000) 

Air  Bawd 

Afe  Board 

STANAGa  80006999 

A0C8A 

Aflad  Conan  and  Camp  Sac  Agency 

P8NWB 

Psckal  Swichod  Nslwoffc 

AD6M 

AMtd  Dm  Systems  kUnpAOMicy 

Procadual  Standards 

PWVQ 

a*  -  - - -  -  -  1 - .  _  - - A_  uu* 

rmnwi  iHmOrwmjf  HU 

WGl 

mnom  iuo  nmptmty  owim 

Ds6a  Unto  10, 11,  and  14 

was 

AfeOparWora 

was 

Land  Fomas  TDS> 

WB4 

btsr-Ssrrics  Dm  8ymm 

OMa  Urda  1,16;  UMS.SSS8;  STANAG  5516 

was 

Ctwacter-Orisnted 

liRBMQtDivilogiiwtbidCoibbnMMMgnl 

was 

IMtfm*  OpsraNont 

war 

bftsOpsnos  Qporteiont 

~  tt  ^Ttitiqit 

was 

Common  Opomionte  Vocmjoy 

BEGAN 

Comm  Socuty  md  Evb  A^mey 

NBQ 

NATO  SMndardbaien  Qmp 

Prspars  CawpaaBa  NATO  Standadhaiun  Psagranawa 
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3.  INTERNATIONAL  STANDARDS  BODIES 

Table  F-3  identifies  standards  bodies  such  as  ITU-TS,  ISO,  and  ECMA  that  recommend,  develop,  and 
maintain  technical  standards  for  communications  and  information  processing.  The  primary  mtemaFonal  bodies  are 
described  below.5  National  standards  bodies  are  identified  in  Chapter  4  of  this  appendix. 


Table  F-3.  Responsibilities  for  Communications  and  Information  Processing 
In  International  Civil  Standards  Bodies 


■mrnirjTTjB 

Title 

Standards 

Responsibility 

Ill»at--MirT7T7Ti7] 

International  Telecommunications  Union  • 

ccm) 

Telecommunications  Standards  Sector 

SOI 

Service  Definition 

SQ2 

Network  Operation 

Tariff  and  Accounting  Principles 

SG4 

Network  Maintenance 

SG5 

Protection  Against  Electromagnetic  Effects 

sae 

Outside  Plant 

SQ7 

Data  Networks  and  Open  System  Communications 

OSI  standards;  facilities, 
interfacess 

WG1 

Network  Services,  FadWies  Prototypes 

WG2 

Network  Access  Interfaces 

WG3 

Internetworking,  Switching,  Signal 

WG4 

Transmission  and  Message  Handing 

was 

Routing,  Numbering,  Layered  Model 

SR  ISON 

ISDN-Related  Issues 

RD&S 

Terms  and  Definitions 

SG8 

Terminals  for  Telematic  Services 

OSI  standards;  FAX,  teletax. 
videotex 

WQ1 

Terminal  Characteristics 

WQ2 

Common  Protocol  &  FntomotWQfldoQ 

SQ9 

Television  and  Sound  Transmission 

SQ 10 

Languages  for  Telecommunications  Applications 

son 

SwheNng  and  Signalng 

SQ  12 

End-to-end  Transmission  Performance  of  Networks  and 
Terminals 

SQ  13 

Genera!  Network  Aspects 

SQ  14 

Data  Transmission  over  the  Telephone  Network 

SQ  15 

Transmission  Systems  and  Equipment 

ItirlMiati 

— 

c&ib ec 

European  Committee  for  Telecommunications  Standardization 

— 

dt&T 

CCH 

— 

CMC 

CLTA 

European  Computer  Manufacturing  Association 

TC29 

Text  Preparation  &  Interchange 

Telematic  services; 
text/office  systems 

5  *La  Galsxie  de  U  NomuUutkm*  [Ref.  Telecoms  1989);  The  OMN1CON  Index  of  Standard*  far  Dbtribmad  Information 
and  Telecommunication  Systems  [Ref.  OMNfOON  1987];  sod  The  Value  and  Use  of  TT  Standard*  in  Pattk  Frocmnmtat 
(Ref.  CEC  1988]. 
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Table  F-3.  Responstoillties  tor  Communications  and  Information  Processing 
In  International  Civil  Standards  Bodies  (Cont’d) 


— T55 - 

Communications,  Networks  &  Systems  Interconnsction 

1  II  i1  i  — 

TQ1 

Public  Date  Networks 

Local  Arse  Networks 

TQ6 

Intsrfaces  to  Private  Switching  Networks 

TG7 

Transport  &  Network  Layers 

Layer  3  and  Layer  4  OSI 
standards 

COS 

Corporation  for  Open  Systems 

Testing 

— 

— 

blSI 

— 

EWOS 

Technology  Committee  on  Information  Processing  Systems 

Promote  standards  worldwide 

.  a4bx. 

Special  Group  on  Functional  Standardization 

ISPs 

SWG-API 

Applications  Programming  Interface  (as  of  August  1983, 

SWG-API  has  been  Absolved)  [Ref.  SC21  N  8081  1993] 

SWG-CA 

Conformity  Assessment  (as  of  August  1993,  SWG-API  has 

been  dissolved)  [Ref.  SC21  N  8081  1993] 

SWG-EDI 

Electronic  Data  Interchange 

Modeling  Faclities  (Note  that  as  of  August  1993,  SWG-MF 

has  been  Absolved)  [Ref.  SC21  N80B1  1993] 

SWG-P 

Procedures 

Registration  Authorities 

SWG-SP 

StrategicPIanning 

SCI 

Vocabulary 

SC2 

Character  Sets  &  Information  Codtog 

see 

Telecommunications  and  Info  Exchange  Between  Systems 

WG1 

Data  Link  Layer 

WG2 

Network  Layer 

WG3 

Physical  Layer 

WG5 

Transport  Layer 

woe 

Private  Integrated  Services  Networking 

SC7 

Software  Engineering 

WQ1 

Symbols,  Charts,  and  Diagrams 

WG2 

System  and  Software  Documentation 

WG4 

Tools  and  Environments 

WG5 

Reference  Model  for  Software  Development 

WG6 

Evaluation  and  Metrics 

WG7 

Ufa  Cycle  Management 

woe 

Integral  Lie  Cycle  Proeessee 

WG9 

Classification  and  Mapping 

sen 

Ftadble  Magnetic  Media  for  Digital  Data  Interchange 

SCI  4 

Data  Element  Principles 

DE  standardization 

WG4 

Coordination  of  Data  Element  Standardization 

SCI  5 

Labeling  and  Fb  Structure 

SCI  7 

Identification  and  Related  Devices 

SC18 

Document  Processing  and  Related  Communication 

MsSaage  Handtog  Protocols 

WG1 

User  Requirements 

WG3 

Office  Document  Architecture' and  Interchange  Format 

ODAAXMF 

WG4 

Procedures  for  Text  Interchange 

MOHS 

WG5 

Content  Architectures 

WG8 

Text  Description  and  Processing  Languages 

WG9 

User  System  Interfaces  and  Symbols 

SC21 

Open  Systems  Interconnection,  Data  Management  and  Open 

OSI  and  other  standards 

Distributed  Processing 

WG1 

OSI  Architecture 

OSI  architecture,  reference 

model,  security,  QOS, 
conformance  testing. 

LOTOS,  Estele 
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Tabte  F-3.  Responsibilities  for  Communications  and  Information  Procosaing 
In  Intomattonal  Civil  Standarda  Bodies  (Cont'd) 


SC2S 

SC28 

SC27 

WGl 


r.-  : 


Open  System*  Interconnection,  Data  Management  and  Open 
Oietributed  Processing 
OSI  Architecture 


Database  (not  part  o(  OSI) 


OSI  Management  and  OSI  Directory 


Open  Distributed  Processing  (not  part  of  OSI) 
OSI  Upper  Layers 


Testing 

Languages 

POSIX 

Internationalization 


Optical  Disk  Cartridges  for  Information  Interchange 
Computer  Graphics  and  Image  Processing 

Architecture 

Appication  Programming  Interfaces 
Metaffles  and  Device  Interfaces 
Language  Bindng 

Validation.  Testing,  and  Registration 
Interconnection  of  IT  Equipment 
Microprocessor  Systems 
Common  Security  Techniques  for  IT  AppKcstions 
Secret  Key  Algorithms  and  Applications 
Pubic  Key  Crypto-systems  and  Modes  of  Use 
Use  of  Encipherment  Techniques  in  Communication 
Architectures 
Office  E 


OSI  and  other  standards 

OSI  architecture,  reference 
model,  security,  QOS, 
conformance  testing, 
LOTOS.  Estate 
SQL.  IRDS,  RDA.  Data 
Management,  Conceptual 
Schema 

CMIS,  CMIP,  systems 
management.  SMI. 
managed  objects. 
Directory 
OOP,  OOP  Trader 
Layers  5-7;  ALS.  XALS. 
ACSE,  ROSE.  RTSE, 
GULS,  RPC.  VT.  FTAM, 
RPC.TP.TM.ASN.1 


Work  formerly  done  by 


forum 


uropean 


\t&i& 


3.1  CEN/CENELEC 

The  Camite  Europeen  de  Nom>sH«ation  (CEN)  is  a  grouping  of  the  national  organization*  of  18 
of  the  European  Community  (EC)  and  the  European  Free  Trading  Association  (EFT A).6  CEN 


6  The  EFTA  is  slso  known  ss  the 
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cooperation  wiib  the  Camite  Earapeen  de  Normalisation  Electrotechniqoe  (CENELEC)  to  develop  md  ptiblufa 
European  standards  [normes  eoropeenoes  (ENs)].  CENELEC  deals  exclusively  with  electrotechnical  standards  and 
CEN  works  with  standards  in  all  other  areas.  Based  in  Brussels,  CEN/CENELEC  works  to  harmonize  standards  that 
are  established  by  its  members  and  to  create  European  standards  where  no  other  appropriate  standards  exist 
CEN/CENELEC  members  mdude  AFNOR  (France),  UNI  (Italy),  DIN  (Germany),  BSI  (United  Kingdom),  IBN 
(BelgiumX  DCQ  (Portugal),  and  SIS  (Sweden). 

CEN/CENELEC  standards  are  initially  distributed  for  comment  by  member  bodies  in  the  form  of  an 
experimental  standard  (ENV7)  or  a  European  prestandard  (prENV).  Future  technical  work  in  developing  proposals  for 
ENVs  has  now  been  taken  over  by  the  European  Workshop  for  Open  Systems  (EWOS).  When  proposed 
international  standards  are  harmonized  with  national  standards,  harmonized  documents  (HDs)  are  produced.  When 
adopted,  an  HD  must  be  used  and  national  deviations  can  only  exist  temporarily.  European  norms  (ENs)  must  be 
adopted  as  national  standards,  and  any  conflicting  national  standards  must  be  withdrawn.  An  example  standard  is 
ENV  41201,  Private  Message  Handling  System.  A  second  class  of  standards  promulgated  by  CEN/CENELEC  are 
the  Telecommunications  European  Norms  (NETs),  which  are  common  technical  specifications  covering  access  to 
networks  and  equipment.  Examples  arc  NET2  (X.25  Access)  and  NET3  (ISDN  Basic  Access). 

CEN/CENELEC  standards  originate  as  draft  documents,  standards  proposals,  and  implementors  guides 
developed  by  various  standards  promoting  organizations.  When  stable,  these  documents  are  reviewed  and  coordinated 
by  the  European  Telecommunications  Standards  Institute  (ETS1)  and  EWOS  and  are  issued  for  comment  as 
functional  specifications,  recommendations,  and  technical  specifications.  When  the  review  is  complete,  they  are 
forwarded  to  CEN/CENELEC,  or  to  the  Conference  Europeenne  des  Posies  et  Telecommunications  (CEPT),  for  final 
standards  development8 

3.2  CEPT/ETSI/UER 

Three  consortia  represent  the  interests  of  public  telecommunication  administrations  of  European  countries. 
The  Conference  Europeenne  des  Posies  et  Telecommunications  (CEPT)  coordinates  political  aspects  and  prepares 
technical  specifications  far  member  administrations  (but  does  not  produce  any  standards).  The  CEPT  has  20  member 
countries  rod  works  closely  with  CEN/CENELEC.  The  European  Telecommunications  Standards  Institute  (ETSI)  is 
an  organization  created  within  CEPT  to  prepare  specifications  concerning  public  telecommunications  networks.  The 
Union  Europeenne  de  Radiodiffusion  (UER)  is  a  technical  committee  with  the  am  of  harmonizing  radio  bmwrtrasting 
system  standards;  its  proposals  are  transmitted  to  the  CCIR  and  the  DEC.  The  UER  has  32  countries  actively 
participating  and  43  associated  member  bodies. 

3.3  Conference  on  Data  Systems  Langaages  (CODAS YL) 

Formed  in  1960,  the  Conference  on  Data  Systems  Languages  (CODAS  YL)  has  been  active  in  the 
development  of  the  COBOL  language,  a  common  Data  Description  Language  (DIM.)  for  defining  schemata  and 
subschemata  and  a  data  manipulation  language. 

3.4  Corporation  for  Open  Systems  (COSyCorpo ration  for  Open  Systems 
Interconnection  Networking  in  Europe  (COSINE) 

The  Corporation  for  Open  Systems  (COS)  and  the  Corporation  for  Open  Systems  Interconnection 
Networking  in  Europe  (COSINE)  participate  in  the  development  of  functional  profiles  for  OSI  and  play  an  active 
role  in  setting  standards  for  testing  OSI  products  for  conformance  to  the  international  standards  and  profiles.  COS  is 
based  in  Vienna,  Virginia,  in  the  United  States,  and  COSINE  is  based  in  Paris. 

COS  has  over  60  member  organizations,  both  vendors  and  users.  Its  goal  is  to  promote  and  accelerate  the 
adoption  of  interoperable,  multivendor  products  and  services  based  on  OSI  and  ISDN  standards.  To  accomplish  this 
goal,  COS  provides  a  user-vendor  forum  for  the  statement  of  user  requirements  and  the  discussion  mid  management 
of  the  issues  surrounding  the  deployment  of  open  systems.  COS  also  identifies  test  requirements  and  sponsors  test- 
tool  development  snd  conformance  and  interoperability  testing  to  verify  that  computer  products  and  services  conform 
to  OSI  and  ISDN  standards. 

COSINE  is  a  project  established  by  the  CEC  to  promote  internetworking  facilities  between  industrial  ad 
academic  research  and  development  commimities  throughout  Europe.  Participating  countries  are  Austria,  Belgium. 
Denmark,  Finland,  France,  Germany,  Greece,  Ireland,  Italy,  Luxembourg,  the  Netherlands,  Norway.  Portugal,  Spain, 
Sweden,  Switzerland,  the  United  Kingdom,  and  Yugoslavia. 

One  COSINE  project  was  establishing  a  pan-European  OSI  data  networking  infrastructure  for  European 
research.  COSINE  is  intended  as  an  enabling  or  catalytic  project  not  a  long-term  operational  activity.  The  Reseaux 


7  The  *V*  In  ENV  is  for  "Vornonn,"  and  indicates  a  standard  bared  on  IMS  or  other  draft  standards  that  are  not  completely 
■table;  modifications  to  ENV  standards  may  eventually  be  required  to  bring  them  in  line  with  international  standards. 
ENVs  are  valid  for  3  yean --they  are  reviewed  after  2  years  and  may  then  become  an  EN,  be  prolonged  for  another  2 
yean,  be  replaced  by  another  ENV,  or  be  withdrawn. 

8  Briefing  on  EUROPE  92-The  European  Community’s  Approach  to  Integration  in  the  Information  Technology  Area 
[Ref.  Griefeostein  1989]. 
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Anodes  poor  Recherche  Europeene  (RARE— Association  of  European  Research  Networks),  which  exists  to 
coordinate  and  promote  networking  activities  for  the  European  research  community,  coaid  add  an  operational  or 
service  role  to  its  present  representative,  promotional,  and  coordinating  functions  and  take  over  my  activities  from 
COSINE  that  remain  necessary  after  the  end  of  the  project9 

3.5  Electric  Power  Research  Institute  (EPRI) 

The  Electric  Power  Research  Institute  (EPRI)  is  a  US  industry  association  of  more  than  670  publicly  and 
privately  owned  utilities  that  is  facilitating  the  use  of  open  systems  technology  in  the  utility  industry.  It  has 
developed  a  Utilities  Cnmmmtications  Architecture  (UCA)  as  a  GOS IP-like  profile.  EPRI's  specific  interests  span 
real-time  UNIX,  expert  systems,  and  database  access  using  RDA  and  SQL. 

3.6  European  Computer  Manufacturer  Association  (ECMA) 

The  European  Computer  Manufacturer  Association  (ECMA)  represents  a  group  of  33  manufacturers  in 
Europe.  Rs  work  is  conducted  by  14  technical  committees.  Based  in  Geneva,  ECMA  acts  as  an  observer  at  ISO  and 
as  a  consultant  at  ITU-TS.  ECMA  takes  an  active  role  in  the  definition  of  functional  profiles  with  EWOS.  ECMA 
contributes  to  the  ISO  standards  development  efforts,  in  addition  to  issuing  its  own  standards.  It  is  particularly 
active  in  the  development  of  higher  layer  protocols  for  OSI  networking  and  is  developing  a  standard  for  a  Portable 
Common  Tool  Environment  (PCTE). 

3.7  European  Manufacturing  Automation  Program  (MAP) 

The  European  Manufacturing  Automation  Program  (MAP)  User  Group  (EMUG)  was  created  in  1983  by  a 
large  group  of  manufacturers.  It  aims  to  promote  the  MAP  standards  in  Europe.  Specific  groups  in  die  nations, 
such  as  the  Club  Infarmatique  des  Gtandes  Enterprises  Prancaises  (CIGREF)  in  France,  are  appointed  to  be  EMUCs 
representatives.  A  key  element  of  MAP,  the  Manufacturing  Message  Specification  (MMS)  has  readied  NS  status 
(DIS  9506). 


3.8  European  Strategic  Programme  for  Research  and  Development  in  Information 
Technology  (ESPRIT) 

European  Strategic  Programme  far  Research  and  Development  in  Information  Technology  (ESPRIT)  is  a 
European  research  program  initiative  begun  in  1962  and  sponsored  by  the  Commission  on  European  Communities, 
to  nugor  work  areas  are  advanced  microelectronics,  software  engineering  aid  technology,  advanced  information 
processing,  office  automation,  and  computer  integrated  manufacturing.  ESPRIT  has  contributed  to  many  standmds 
projects,  such  as  PCTE,  Communications  Network  for  Manufacturing  Applications  (CNMA),  and  Herode,  which 
has  prepared  an  office  document  architecture  standard  for  adoptionby  ISO.  The  future  focus  of  ESPRIT  will  be  on 
developing  microelectronics  and  peripheral  technologies,  creating  technologies  and  tools  for  the  design  of 
information  processing  systems,  and  enhancing  the  capacity  for  using  and  integrating  information  technology  to 
extend  the  scope  of  its  applications. 

3.9  European  Workshop  on  Open  Systems  (EWOS) 

The  European  Workshop  on  Open  Systems  (EWOS)  promulgates  harmonized  technical  proposals  for 
functional  profiles  of  OSI  standards  and  corresponding  conformance  test  specifications  EWOS  has  been  given  the 
responsibility  for  technical  work  in  developing  proposals  for  ENVs,  with  increased  involvement  of  users.  When 
complete,  the  proposals  are  submitted  to  GEN/CENELEC.  The  founding  members  of  EWOS  include  CEN, 
CENELEC,  ECMA,  EMUG,  OSITOP,  RARE,  and  the  Corporation  for  Open  Systems  Interconnection  Networking 
in  Europe  (COSINE).  The  member  bodies  of  EWOS  have  agreed  not  to  undertake  an  their  own  miy  new  work  on 
the  development  of  functional  standards.  The  focus  is  now  on  development  of  profiles  (ISPs). 

3.18  Information  Technology  Steering  Technical  Committee  (TTSTC) 

The  Information  Technology  Steering  Technical  Committee  (ITSTC)  provides  recommendations  for 
European  members  in  three  areas:  standards  (the  Information  Technology  Ad-hoc  Expert  Group  for  SttndwdsX 
mramfatauring/antnmation  (the  Information  Technology  Ad-hoc  Expert  Group  for  Manufacturing),  and 
(the  Information  Technology  Ad-hoc  Expert  Group  for  Certification).  While  the  rTSTC  does  not  produce  standards, 
it  does  define  programmes  for  European  standards  and  organizes  and  coordinates  the  waric 

3.11  International  Federation  for  Information  Processing  (IFIP) 

The  International  Federation  for  Information  Processing  (IFIP)  is  a  group  of  international  experts  drawn 
principally  from  universities  and  also  from  some  industries  (e.g„  Xerox,  Beil).  IFIP  has  contributed  to  die  work  of 
ISO  on  dm  OSI  model  and,  more  recently,  to  the  work  on  X.400-type  message  handling  systems. 


9  "COSINE  on  Twget  for  1992*  [Ref.  OSN  1991n] 
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3.12  International  Orgaaliattaa  for  Standardization  (ISOyinteraa  ttena I 
Bbdrotediaial  Commission  (IEC) 

The  International  Organization  for  Standardization  (ISO)  has  89  representing  — standards 

bodies  (e.g.,  AFNOR  hi  France,  JISC  in  Japan,  ANSI  in  the  United  Stales,  BSI  in  the  United  Kingdom).  The 
International  Bcctmlrrtwical  Commission  (IEC)10  is  a  federation  of  more  than  200  national  committees  working  in 
the  area  of  electronics  and  electrical  standards  with  specific  interest  in  infonnatioo  processing.  ISO  and  IEC  have 
formed  a  joint  committee,  Joint  Technical  Committee  One  (JTC1),  to  develop  standards  for  information  processing 
systems. 


3.13  Internet  Activities  Board  (1AB) 

The  LAB  is  a  committee  of  researchers  and  professionals  that  manages  the  technical  standards  and 
architecture  of  the  Internet,  a  collection  of  more  than  5,000  packet-switched  networks  world  wide,  80  percent  of 
which  arc  in  the  United  States  To  maintain  imiformity  within  the  network,  LAB  approves  Internet  Standards  and 
manages  the  process  by  which  they  are  published. 

3.14  ISO  Development  Environment  (1SODE)  Consortium 

The  ISODE  Consortium  was  farmed  in  1992  to  take  charge  of  further  development  of  ISODE,  a  public- 
domain  implementation  of  OSI,  and  ‘‘commercialize’'  k.  The  Consortium  aims  to  position  ISODE  as  a  package  an 
which  vendors  can  build  OSI  products  and  to  support  its  continued  use  in  the  researdi  community.  The  Consortium 
is  a  professional  non-profit  corporation,  the  initial  start-op  of  which  was  achieved  by  funding  from  the 
Microelectronics  and  Computer  Technology  Corporation  (MCQ  in  Austin,  TX.  [Ref.  OSN  l992o] 

3.15  International  Telecommunications  Union  •  Telecommunication 
Standardisation  Sector  (ITU-TS)  (formerly  CCITT/CCIR) 

The  International  Telecommunications  Union  -  Telecommunication  Standardization  Sector  (ITU-TS) 
[formerly  the  Comite  Coosultatif  International  pour  le  Telephone  et  le  Telegraph  (COTT)  and  International  Radio 
fnwaniwriw  rViMwitm*  {fyitt)]  nw  nt  timnr.  swvnrs  nf  thr  mi,  >  ttnimt  Nations  u»eiy  organization.  The  other 
two  sectors  arc  Radiocommunication  and  Telecommunication  Development.  The  ITU  groups  all  the  Postal 
Telephone  Telegraph  (PTT)  administrations  of  the  world's  countries.  ITU-TS  develops  standards  in  4-year  cycles  and 
works  closely  with  ISO  to  harmonize  results.  It  is  based  in  Geneva. 

ITU-TS’s  primary  mission  is  to  develop  standards  supporting  the  international  imercounectian  and 
interoperability  of  telecommunications  networks  at  interfaces  with  end-user  systems,  carriers,  information  and 
enbanoetNervloe  providers,  and  customer  premises  equipment.  Its  recommendations  arc  mandmory  in  Europe  where 

3.14  Message-Oriented  Middleware  Consortium  (MOM) 

The  Message-Oriented  Middleware  Consortium  (MOM)  [Ref.  Stahl  1993]  is  a  new  middleware- vendor 
association  (see  Section  13.5).  MOM  promotes  middkwwe  that  uses  messaging  tedmoiogy  to  allow  applications  to 
communicate  across  distributed  platforms.  Consortium  members  indude  Digital  Equipment.  IBM,  and  Covia 
Technologies.  The  intent  of  the  consortium  is  to  create  standards  in  messaging  middleware. 

3.17  National  Information  Infrastructare  Testbed  (NUT) 

The  National  Infonnatioo  Infrastructure  Testbed  (NUT)  is  a  consortium  of  representatives  from  US  industry, 
academia,  and  government  that  was  formed  in  September  1993  to  leverage  the  National  Information  Infrastructure 
(Nil)  vision  and  principles.  NUT  will  implement  the  vision  of  the  NH  through  the  development  of  distributed 
applications  requiring  the  speed  and  transmission  capacity  of  a  true  data  superhighway  system. 

3.18  National  Protocol  Support  Center  (NPSC) 

An  Australian  organization,  the  National  Protocol  Support  Center  (NPSC)  was  farmed  in  1986  as  a  joint 
effort  between  industry  and  government  to  promote  the  adoptions  of  OSI  stendards  in  formation  technology  and  to 
support  conformance  testing  capabilities  in  Australia. 

3.19  Network  Management  Forum  (NM  Forum) 

The  NM  Forum  is  an  international  consortium  aiming  to  accelerate  and  promote  international  standards  for 
network  management  The  Forum  does  not  create  products  or  standards,  but  instead  specifies  interfaces  and  profiles 
that  promote  the  use  of  standards  among  vendors.  Originally  launched  in  1988  as  the  OSI  Network  Management 
Forum,  the  group  became  the  NM  Forum  in  1990  reflecting  its  inclusive  attitude  to  management  standards.  It  is 
developing  a  roadoap  (EWOS/TZ/91/214)  that  is  an  industry-accepted,  standards-hased  concept  that  promotes  product 
interoperability.  Tbe  Roadmap  plan  is  a  path  consisting  of  a  series  of  points  in  time  (OMNIPoma).  At  each  point 


10  The  xfiC  is  also  known  as  the  Commission  Bectrotechniqoe  Internationale  (CEI). 
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it  is  agreed  that  it  is  sensible  to  build  interoperable  management  products  to  agreed  interfaces  with  agreed 
functionality. 11 

3.29  Object  Management  Group  (OMG) 

OMG  specifies  standard  interfaces  for  object-oriented  software.  It  was  formed  in  April  1989  by  9  companies 
and  now  has  more  than  145  member  organizations  comprised  of  vendors,  software  developers,  and  users.  It  arms  to 
establish  a  framework  and  supporting  specifications  for  commercially  available  object-oriented  environments.  It  has 
created  a  reference  model,  the  Object  Management  Architecture.  OMG’s  object  request  broker  design-key  software 
needed  to  allow  disparate  open  systems  to  request  object  services  from  remote  sites-is  commonly  supported  by 
object-oriented  software  vendors. 

3.21  Open  Document  Architecture  Consortium  (ODAC) 

Six  major  international  computer  companies  formed  the  Open  Document  Architecture  Consortium  (ODAC) 
in  early  1991  to  develop  a  toolkit  of  software  that  conforms  to  the  ISO  ODA  standard.  The  toolkit  will  be  openly 
licensed  to  allow  other  computer  companies  and  systems  developers  to  build  software  applications  using  ODACs 
published  specifications.  It  is  expected  to  be  available  in  1993.  The  consortium  members  ate  currently:  Digital, 
ICL,  Siemens  Nixdorf  Mormationsy  steme,  Groupe  Bull,  IBM,  and  Unisys.  The  Consortium  has  been  established 
as  a  European  Economic  Interest  Group  in  Brussels.  [Ref.  OSN  1991b,  24] 

3.22  Open  Software  Foundation  (OSF) 

Created  in  1988,  the  Open  Software  Foundation  (OSF)  is  a  nonprofit,  inieniational  consortium  of  over  90 
information  systems  companies  (including  International  Business  Machines)  for  the  promotion  of  standards,  such  as 
the  POSIX  standard  for  operating  system  interfaces.  Its  goals  indude  the  development  of  software  specifications  and 
test  tulles  for  an  open  computing  environment.  OSF  specifications  ate  defined,  and  software  developed,  using  an 
open  process  into  which  vendors  and  users  have  input  and  access.  The  resulting  AES  specifications  are  available  in 
the  public  domain  and  its  software  licensable.  Both  members  and  nonmemben  can  submit  technologies  for 
consideration  as  an  OSF  specification  or  offering  through  a  request  for  technology  (RFT)  process.  OSFs 
specifications  and  software  are  based  on  POSIX,  a  variety  of  international,  national,  and  industry  standards  and  other 
fnmnrth  specifications 

3.23  Open  Systems  Testing  Consortium  (OSTC) 

Members  of  the  OSTC  provide  third  party  OS1  conformance  testing  for  wide  area  networking  products  at  a 
number  of  test  laboratories  throughout  Europe.  It  is  an  international  organization  encompassing  PTTs,  public 
network  operators,  manufacturers,  and  research  organijatiou*. 

3.24  OSI  Multipeer/Multicast  (MPMC)  Consortium 

The  OSI  MPMC  Consortium  has  been  formed  under  the  National  Science  Foundation’s  Industry/Arartrmia 
Cooperative  Research  Program  at  North  Carolina  State's  Center  for  Communications  and  Signal  Processing.  The 
Consortium  presently  has  three  subscribing  members:  the  DoD  DISA/JIEO,  the  US  Army's  Project  Manager  for 
Training  Devices,  and  the  US  Army  Communicatioru- Electronics  Command  Software  Engineering  Directorate. 
Four  academic  institutions  (University  of  Delaware,  University  of  New  Hampshire,  University  of  Central  Florida, 
and  North  Cvolina  Stale  University)  ate  presently  participating  and  contributing  to  the  research  and  progression  of 
the  MPMC  work,  and  two  consultants  (Open  Network  Solutions  and  the  MOSAIC  Group)  ate  progressing  standards 
development  under  previously  existing  projects.  The  goal  of  the  consortium  is  to  produce  standardized  MPMC 
communications  environments  with  coopcrativc/levcragcd  resources  of  the  interested  and  benefiting  patties.  The 
areas  it  plans  to  address  include  standards,  progression,  formal  specifications,  PICS  Proforma,  coofbrmance  and 
interworking  testing,  MPMC  testbed,  OSI  MPMC  network,  and  performance-cost  tools.  In  addition,  it  will  conduct 
Cora  three  times  per  year.12 

3.25  OSINET 

OSINET  was  formed  in  1984  trader  the  auspices  of  NIST.  Governed  by  its  membership  it  works  in  three 
specific  areas:  (1)  the  research  and  development  of  test  scripts  that  are  used  in  OSI  interoperability  testing.  (2)  the 
interoperability  testing  and  registration  of  amotraced  OSI  products,  and  (3)  the  demonstration  and  promotion  of  ISO 
technology.  Tire  US-based  organization  comprises  55  members  and  recently  voted  to  reorganize  under  the  auspices 
of  COS  [OSN  1991b,  23]. 

3.2i  ositop 

Open  Systems  Interconnection  for  Technical  and  Office  Protocol  (OSITOP)  is  an  association  of  users  (such 
as  BNP,  EDF/GDF)  for  the  promotion  of  ISO  functional  profiles  and  the  concept  of  TOP. 


11  "A  Roadmap  for  Open  Management”  [Ref.  OSN  1992e]. 

1 2  Open  Systems  Interconnect  (OS!)  Multipeer/Mnlticast  (MPMC)  Prospectus  [Ref.  MPMC  1991). 
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3.27  PCTE  btirfaci  Miw|wt  Board  (P1MB)  Association 

The  PCTE  Interface  Management  Board  (P1MB)  Association  is  a  non-profit  international  company  whore 
pupate  is  lo  promote  greater  me  of  the  PCTE  interface  and  to  encourage  development  of  tools  and  software 
enghmering  methodologies  using  PCTE.  It  was  established  in  May  1992  but  has  its  origin  within  the  PIMB,  an 
informal  group  formed  in  October  1986  to  coordinate  standardization  and  exploitation  erf  several  PCTE-based 
ESPRIT  (European  Strategic  Programme  for  Research  into  Information  Technology)  projects.  Since  1986,  PIMB 
has  grown  to  35  worldwide,  including  IT  users,  tool  suppliers,  computer  manufacturers,  software 

companies,  and  PCTE  environment  suppliers.  [Ref.  Vemocchi  1992] 

3.28  Petrochemical  Open  Software  Corporation  (POSC) 

Petrochemical  Open  Software  Corporation  (FOSQ  was  founded  in  1990  by  a  group  of  major  oil  companies 
to  the  development  of  integrated  computing  technology  for  the  exploration  and  production  segment  of  the 

international  petroleum  industry.  Membership  now  includes  exploration  and  production  service  companies,  software 
vendors,  computer  manufacturers,  and  research  institutes.  POSC  is  focusing  on  the  development  of  an  industry- 
standard,  open-systems-based,  software-integration  profile  for  exploration  and  production  applications  that  will  define 
common  interfaces  between  software  applications,  database  management  systems,  workstations,  and  users.  This 
work  indudes  development  of  an  integrated  data  model,  a  common  look  and  feel  for  user  interfaces,  and  a  set  of  test 
suites. 


3.29  Promotion  Conference  for  Open  Systems  Interconnection  (POSiyiNTAP 

Created  by  six  mqor  vendors  in  Japan  and  the  Nippon  Telephone  and  Telegraph  (NTT)  Corporation,  the 
Promotion  Conference  far  Open  Systems  Interconnection  (POSI)  is  the  equivalent  to  SPAG  in  Europe  mid  to  COS 
fat  the  United  Stales.  POSI  is  an  Asia-Oceania  regional  forum  for  the  international  workshops  on  OSI,  and  as  such, 
seeks  agreements  among  vendors  to  ensure  interoperability  and  compatibility  of  products.  The  POSI  regional 
woricsbop  is  known  as  the  Asia-Oceania  Workshop  (AOW). 

POSI  will  use  the  conformance  testing  tools  and  services  developed  by  the  Interoperability  Technology 
Association  for  Information  Processing  (INTAP).  INTAP  is  a  national  agency  of  Japan,  funded  by  MITI,  that  deals 
with  information  technology,  specificaDy  OSI  products  and  advanced  prefects. 

3.39  SQL  Access  Group  (SAG) 

The  SAG  is  a  non-profit  corporation  set  up  by  vendors  and  users  to  develop  technical  specifications, 
including  APIs,  to  enable  multiple  relational  databases  and  application  tools  to  work  together  using  the  SQL 
standard.  Its  goals  are  to  define  a  common  subset  of  SQL  fimetioos  (e.g.,  SQL  data  format,  protocols  for  moving 
data  within  a  multivendor  environment)  in  order  to  reconcile  the  many  SQLs  that  exist  and  to  specify  an  cnhanml 
SQL  programming  interface  that  will  let  developers  write  a  single  application  that  can  access  a  variety  of  SQL 

3.31  Standards  Application  and  Promotion  Group  (SPAG) 

The  Standards  Application  and  Promotion  Group  (SPAG),  based  in  Brussels,  was  created  in  1983  by  12 
major  European  manufacturers  (e.g..  Bull,  Id,  Siemens)  and  now  includes  about  65  information  technology 
manufacturers  and  users.  SPAG’s  goals  are  to  promote  multivendor,  interoperable  products  based  on  international 
standards,  particularly  OSI,  and  to  keep  its  members  informed  about  the  blest  developments  hi  functional  standards 
and  conformance  testing  of  products.  SPAG  seeks  to  accelerate  standardization  by  selecting,  among  all  OSI 
«««*«*  i  "wmtwrfnr  The  stacks  of  standards  are  called  profiles  and  are  developed  toward 

supporting  complete  applications,  such  as  FT  AM.  SPAG  has  made  a  major  contribution  to  the  rapid  progress  of 
European  experimental  standards  (ENVs)  and  standards  (ENs).  It  plays  a  leading  role  in  EWOS,  regularly  publishes 
the  Guide  to  the  Use  of  Standards,  and  participates  in  development  of  ISPs.  However,  an  August  1993  article  stales 
that  the  future  of  SPAG  is  in  the  balance  thanks  to  the  slow  take-off  of  OSI  and  the  world  recession.  Following 
warnings  from  sponsors  tint  Binding  could  not  be  guaranteed  next  year,  SPAG's  director  most  dram  up  outside 
business  before  the  end  of  the  financial  year,  or  lay  off  staff.  [Ref.  OSN  1993o] 

3.32  Support  to  the  Commission  of  ths  European  Community  (CEC) 

The  Senior  Official  Group  for  Information  Technology  Standardization  (SOGITS)  and  the  Senior  Official 
Group  an  Telecoamunicationt  (SOGT)  assist  the  CEC  in  the  implementing  legislation  for  information  technology 
standards.  The  Public  Procurement  Subcommittee  in  the  Information  Technology  Sector  (PPSC-IT)  enforces  the 
role  of  standards  in  public  procurement  for  the  CEC. 

3.33  UNIX  International  (UI) 

UI  is  a  product-specific  open  systems  organization,  bat  it  does  not  sell  or  license  any  software  products 
itself.  It  directs  the  development  of  UNIX  System  V  and  rebued  products,  the  majority  of  which  are  developed  and 
•old  by  UNIX  System  Laboratories,  a  partly  owned  subsidiary  of  AT&T,  the  originator  of  UNIX.  UI  was  formed  in 
1988  and  claims  225  members.  In  late  1992,  it  was  sold  to  Novell. 
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3.34  X.4M  API  AMMlatioa  (ANA) 

APIA,  fanned  is  1989,  is  a  group  of  more  than  20  computer  and  communications  vendors  working  to 
facilitate  the  transfer  of  messages  between  all  dactronic  message  systems,  specifically  for  use  on  local  area  networks 
of  personal  computers,,  through  development  and  promotion  of  practical  interfaces  based  on  the  lTU-TS's  X.400 
recommendations.  The  APIA  is  working  id  develop  interfaces  to  message  handling  systems  for  use  by  a  variety  of 
applications  such  as  gateways  to  other  messaging  systems,  EDI,  etc.  In  conjunction  with  X/Open,  APIA  completed 
in  1990  an  X.400  API  specification.  It  has  also  contributed  to  the  IEEE  P1224  standard. 

3.35  X/Open 

X/Open  is  an  independent,  non-profit  consortium  formed  in  1984  to  determine  user  and  market  requirements 
and  to  specify  a  complete,  source-level-portable  application  environment  and  test  suites.  Although  Ms  members  were 
initially  vendors,  its  membership  bow  encompasses  users,  system  integrators,  value-added  resellers,  government 
agencies  worldwide,  other  industry-standards  groups,  and  academic  and  research  organizations.  X/Open  is  developing 
extensions  to  UNIX  SVID  operating  system  standards  to  support  a  distributed  transaction  processing  environment 
that  meets  OSI  standards.  X/Open  is  developing  a  Common  Applications  Environment— which  includes 
specifications  for  an  operating  system  interface,  networking,  data  management,  programming  languages.  Poppy  disk 
fonnats,  internationalization,  and  distributed  transaction  processing — to  promote  software  portability.  Alignment  of 
both  activities  with  the  emerging  POS1X  standards  is  planned. 
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4.  NATIONAL  STANDARDS  BODIES 


This  section  identifies  national  standards  bodies  and  their  responsibilities  far  standards  development  or 
13  Aridirkml  contributions  to  this  section  woold  be  welcomed. 


4.1  Belglnm 

Hie  Institat  Beige  de  Normalisation  (IBN)  is  the  primary  standards  body  for  Belgium. 

4.2  Canada 


The  Canadian  Standards  Association  (CSA)  is  responsible  for  the  development  of  OSI  standards  in  Canada. 
The  Standards  Coaadl  of  Canada  (SCC)  is  a  Canadian  national  non-governmental  agency  that  developa  standards 
policy.  The  SCEprovMmcoardinatioo  and  support  for  the  National  Standards  System  (N&)  and  mppora  Canada's 


4.3  Denmark 

Danish  Standards  Association  (Dansk  Standardiseringsrad)  U  the  ISO  member  body  from  Denmark.  bis 
•ho  the  member  body  for  CEN. 

4.4  Fkwnce 

The  Association  Practise  de  Normalisation  (AFNOR)  is  the  Preach  official  organization  for 
norraiBratioufttasidardizalkia  sod  die  French  member  body  for  ISO.  It  works  with  manufacturers,  users,  and 
adminiilraiinn  h  promulgates  international  standards  in  Fiance,  chooses  working  groops  in  which  France  is  to  take 
an  active  part,  msnages  French  technical  experts,  sod  defines&oordhunes  the  proposals  they  most  put  forward  in 
discussions.  The  AFNOR  role  also  inclndes  giving  infonnation-it  sends  oot  literature  on  national  and  international 
standards  and  answers  questions  from  manufacturers  and  users.  AFNOR  standards  are  classified  according  to  the 
activity  to  which  they  relate.  For  example.  Class  Z  corresponds  to  data  processing.  The  Union  Technique  de 
fElectticite  (UTE)  is  the  member  of  CENELEC  from  France  and  an  active  participant  in  AFNOR  for  the 

riewflnpmwM  nl  CTpInlt—tnmf  Wwttri*  »lar»ririty  end  riarirnnir* 


4.5  Germany 


Hie  DentachalnstitmftaNonnBng  (PIN)  is  the  official  organization  for  standardization  for  the  Federal 
RepdbHc  of  Germany  and  Beilin  (West)  and  is  the  member  body  of  ISO  and  CEN. 

4.5  Netherlands 

The  Nnderiands  NonnaHsatie^Insttamt  (NNI)  is  the  ISO  member  body  for  the  Netherlands.  When  ISO  or 
1TU-TS  standards  are  translated  or  modified,  they  are  issued  by  NNI  as  NENs.  For  example,  NEN-ISO  3309  is  a 
translation  of  an  ISO  HDLC  standard. 

4.7  United  Kingdom 

The  British  Standards  Institute  (BSI)  is  the  UK  member  of  ISO  and  the  recognized  body  for  the  preparation 
and  promnlgsl  ion  of  British  national  standards. 

4.t  United  States 

Tie  American  National  Standards  Institalc  (ANSI)  is  the  US  member  of  ISO  and  a  U.S.  dcariaghomc  for 

Table  F-4  identifies  ANSI  and  other  standards  bodies1 4  in  the  United  States,  both  civil  and  military,  that 
recraimmrt,  develop,  managr,  and  maintain  technical  standards  for  comnwaiications  and  information  processing. 

Table  F-5  identifies  all  the  current  Technical  Committees  (TCs)  earnestly  active  in  ANSI  for  Information 
Processing  Systems  (X3). 

In  the  United  Stales,  the  process  of  defining  standards  is  voluntary  and  is  coordinated  by  ANSI.  ANSI 
flGQRBttti  QEJflBiZfltiOIIS  SQCfa  H  pfQftttiOBlI  Nld  iQCfaoiQl  |OClCtl6S|  tIVte  AMOdfltiOB&e  Qf  COOSBBKST  ttd  UbQT  £|OQpE 

to  develop  or  adopt  standards  in  various  areas.  Three  types  of  organizations  can  create  a  standard;  (1)  Accredited 
Sponsor(AS),(Z)  Accredited  Organization  (AO),  and  (3)  Accredited  Standards  Committee  (ASC)  [Ref.  CargiD  1989], 


13  The  OUNICON  Mm  of  Standard!  for  Dittributtd  Information  and  TtUcommunication  Syttonu  [Raf. 
OMNICON  1917). 

14  Similar  tSUas  assd  to  be  dsvalopad  for  standards  bodiss  ia  otter  nations.  Additional  contributions  will  bs  included  in 
future  editions  of  this  wotting  papsr. 
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Table  F-4.  RasponsR>illtias  tor  Communications  and  Information  Procaaalng 

in  US  Standards  Bodies1* 


■arniiKiiMiB 

H  ™"~~"  Title 

—  1  II  MB  1  1  III  III  — 

Information  Procaeaing 

X3S3 

Technology  Committee  (TC)  on  Data 

Devel  of  US  OSI  standards;  input  to  ISO 

Communications 

JTC1/SC21 

X3S3.1 

Task  Group  on  Data  Communications  Planning 

General  standardization  efforts 

X3S3.2 

Task  Group  on  Communications  Vocabulary 

Data  transmission  vocabulary 

X3S3.3 

Task  Group  on  Network  Layer 

Directory,  management,  routing.  ISON 

X3S3.4 

Task  Group  on  Control  Procedures 

Protocols,  procedures,  &  management;  . 
X  25 

X3S3.5 

Task  Group  on  Communications  Systems 

Nomenclature,  presentation  & 

Performance 

performance  measurement 

X3S3.7 

Task  Group  on  Public  Data  Network  Access 

ISDNs,  gateways  (X3.100,  X25,  X.75, 
X32) 

X3T2 

Technology  Committee  on  Data  Interchange 

X3T3 

Technology  Committee  on  OOP 

X3T4 

Technology  Committee  on  Security  Techniques 

X3T5 

Technology  Committee  on  OSI 

Development  of  US  OSI  standards;  input 
to  ISO  JTC1/SC21 

X3T5.1 

OSI  Architecture;  Reference  Model 

FDTs;  Conf  Testing;  Sec,  Open  Distributed 

X3TS.4 

Task  Group  on  OSI  Management  Protocols 

Management,  MIS,  directory  service 

X3T5.S 

Presentation  and  Application  Layers 

CL  mode,  VT,  ASN.1 

X3T5.7 

Task  Group  on  OSI  Security  Techniques 

X3T6 

Task  Group  on  Non-Contact  Information  Systems 
Interface 

X3T7 

Internationalization 

X3T8 

Fault  Tolerance 

X3T9 

Technology  Committee  on  I/O  Interface 

X3T9.2 

Task  Group  on  Lower  Level  Interface 

X3T9.3 

Task  Group  on  Device  Level  Interface 

X3T9.5 

Task  Group  on  Local  Distribution  Data  Interface 

X3V1 

Office  and  PuMshing  Systems 

X3V1.1 

Task  Group  on  User  Requirements  M.S.T. 

X3V1.3 

Task  Group  on  Document  Architecture 

X3V1.4 

Task  Group  on  Text  Interchange 

X3V1.6 

Task  Group  on  Content  Architecture 

X3V1.8 

Task  Group  on  Text  Description  and  Process 
Language 

X3V1.9 

Task  Group  on  User  Systems  Interfacs/Symbols 

X3V1.10 

task  Group  on  Font  Resources 

|l,:>>  1 1 

NC 

National  Committee 

QS-A 

Telecommunication  Policies  &  Services 

SG-B 

WATTC-1988 

— 

SG-C 

WOtKJwKJO  ICNpnont  NffWOrK 

SG-0 

Data  and  ISDN 

JWP 

Joint  Working  Party  on  ISDN 

Institute  for  Electrical  and  Electronic  Engineering 

Computer  Terminology 

_ 

Committee  on  Local  Area  Networks 

PI  003 

POSIX 

_ 

P1201 

Graphical  User  Interfaces 

SCVVUI 

Steering  Committee  on  User  Interface 

DSSC 

Distributed  Services  Steering  Committee 

PSC 

Profle  Steering  Committee 

1 5  Updated  from  X3  Project*  Manual  X3&D-4,  July  1993  (Ref.  ANSI  1993). 
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Table  F-4.  Responsibilities  tor  Communications  and  Information  Proeaaalng 

in  U8  Standards  Bodiaa  (Cont'd) 


1S55 - 

Corporation  for  Open  Syatoma 

Promote  OSI;  conformance  testing 

XXDPEN 

XOPEN 

Promote  portability  and  use  of  OSI 

NIST 

National  Institute  for  Standards  & 

Standards  development  and  coordination; 

Technology 

conformance 

V/vi  1 :  ■ : 

Min  Ini  hi1  1 

Develop  design-to  functional  profiles 

r jrrcn  >r 

DAS0C3 

Deputy  Assistant  Secratary  of  Defense  C3 

T4TC3 

Theater  and  Tactical  C3 

Interoperability  of  C3  systems 

IS 

Information  Systems 

DoO  transition  to  GOSIP 

is-rr 

Infoimation  System — Information 

Corporate  information  management,  DoD 

Technology 

data  standardization,  functional  process 
improvement 

ASDfPAL) 

Production  and  Logistics 

Standards  development 

S&DS 

Standardization  &  Data  Management 

Distribution  of  standards 

6ia 

Defense  Intelligence  Agency 

DISA  (fotmsriy  OCA) 

Defense  Information  Systems  Agency 

DoD  Executive  Agent  for  data  comm 

protocol  standards 

DCS  Organ 

Defense  Communications  System 

Organization 

JIEO 

Joint  Tactical  C3  Agency 

Lead  for  tactical  communication  technical 

standards 

JINTACCS 

Joint  Interoperability  Tactical  C2  Systems 

Joint  message  standards 

Program 

JMSWG 

JTIDS  Message  System  WG 

TADIL  J;  J-Series  messages  and  protocols 

FSSG 

Fire  Support  Subgroup 

K-Series  massages  (and  protocols) 

DMTD 

Digital  Message  Transfer  Device  Subgroup 

MIL-STD-200-220 

DTMP 

DCPS  Technical  Management  Panel 

DoD  data  communications  (including  OSI) 

standards  development 

JITF 

Joint  Interface  Test  Force 

Testing  Joint  Interfaces 

JITC 

Joint  Interoperability  Test  Center 

Testing  Joint  interfaces 

CM 

Corporate  Information  Management 

Data  standardization,  data  administration. 

functional  process  improvement 

JDSSC 

Joint  Data  Systems  Support  Center 

JSC 

Joint  Steering  Committee 

Develop  common  interoperabMty 
standards 

DLA 

— 

N&A . ~~\ 

National  Security  Agency  j 

Security  criteria  and  standards 

jcsj^j  ■—“"“"I 

Ensure  interoperability  of  TDSe 

MCEB 

Coordinate  representation  to  international 

Board 

standards  bodies 

USAf)ISC4 

Director,  Information  Systems  for  C4 

Technical  requirements,  interoperability 

SA1S-ADO 

RSI-Rstionaizstion,  Standards,  & 
Interoperability 

Interoperability  and  standards 

DCSOPS 

International  RSI 

Operational  requirements,  interoperability 

PEO  CCS 

PEO  Command  4  Control  Systems 

Interoperability  of  Army  Tactical  C2 
Systems 

PEO  Comm 

PEO  Communications 

Interoperability  of  Communications 

Systems 

AMC 

Army  Materiel  Command 

Materiel  standards 

ICP-M 

Office  of  international  Cooperative 
Programs 

CECOM 

Communications  4  Electronics  Command 

TRADOC 

Training  and  Doctrine  Command 

Operational  and  procedural  standards 

CAC 

Combined  Arms  Command 

SKJCEN 

Signal  Center 

Communications  standards 

USAISC 

Information  Systems  Command 

ISEC 

Information  Systems  Engineering 

Command 
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Table  F-4.  Reaponsfeillties  for  Communications  and  Information  Procsssing 
in  U.S.  Standards  Bodies  (Cont’d) 


ABN 

REAS/C3IASpece 

CNCTSPAWAR 

Information  Manegamant 

C3I  and  Space 

Spec*  &  Naval  Warfare  Systems 

Command 

Specs &C2 

Information  Management  Support 

Naval  Data  Automation  Command 

CN0TSpece,C2 

OP-946 

NAVQAC 

USMC  Systems  $1 
Command 

MOCDC-WFC 

HQMC  (C412)  04 
DivPAI 

Syeteme  Integration 

WarfigMng  Cantor 

Planning  and  IntsroperabMty 

Standards 

Requirements 

Standards  coordination 

USAFAQDASC4F 

ACSC4Sya 

AFOommCmd 

AFSC 

BSD 

RADC 

ACC 

Acqutsitiona-C4 

C4  Syatama 

Communbalona  Command 

Air  Fores  Syatama  Command 

Electronic  Systems  Division 

Rome  Air  Development  Center 

Air  Combat  Command  (air  component  of 
Atlantic  Command) 

— 

Table  F-5.  ANSI  X3  Technical  Committeee1* 


OCRandMtCR 

xajTe"' 

C++ 

X3J17 

Prolog 

X3B5 

Digital  Magnetic  Tape 

X3J1A 

REXX 

X3B6 

Instrumentation  Tape 

X3J19 

Xbaae 

X3B7 

'  Magnetic  Disks 

X3J20 

SmaMalt 

X3B0 

Paper  Forma/Layout 

X3B10 

Identification  Cards  A  Related  Devices 

X3K5 

Vocabulary 

X3B11 

Optical  Digital  Data  Disks 

X3L1 

Spatial  Data  Transfer 

X3H2 

X3L2 

Codes  &  Character  Seta 

X3H3 

Computer  Graphics 

X3L3 

Audta/Ptcture  Coring 

X3H4 

Information  Resource  Dictionary  System 

X3L8 

Data  Reprsaentation 

X3H6 

Parallel  Processing  Constructs  for  High 

Laval  Programming  Languages 

X3H6 

Case  Tool  Integration  Modal 

X3S3 

Data  Communications  (lowar  layere) 

X3H7 

Object  Information  Management 

X3T2 

Data  Interehange 

X3J1 

PL/1 

X3T3 

Open  Distributed  Processing 

X3J2 

BASIC 

X3T4 

Security  Techniques 

X3J3 

FORTRAN 

X3T5 

Open  Systems  Interconnection  (upper 
layers) 

Non-Contact  Information  Syatama  interface 

X3J4 

COBOL 

X3T6 

X3J7 

APT 

X3T7 

Internationalization 

X3J9 

PASCAL 

X3T8 

Fault  isolation 

X3J10 

APL 

X3TW 

I/O  Interface 

X3J11 

C 

X3J12 

DIBOL 

X3V1 

Text:  Office  A  Publishing  Systems 

X3J13 

Common  LISP 

X3J14 

FORTH 

X3W1 

Office  Machines 

X3J15 

DATABUS 

16  Updated  ban  X3  PnJtcU  Hamul  X3AD-4,  July  1993  [Ref.  ANSI  1993]. 
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Under  die  AS  method,  an  organization  sponsors  a  drive  for  standardization  and  begins  the  canvass  method 
by  inviting  comments  on  the  proposed  standard  from  anyone  who  cares  or  may  be  materially  affected  by  it  This 
method  is  appropriate  only  when  substantial  agreement  on  the  document  to  be  standardized  already  exists,  as  was  the 
case  with  the  Ada  programming  language  standard  [Cargill  1989, 104], 

In  the  AO  method,  an  existing  group  completes  a  standard  in  an  area  in  which  it  has  direct  and  material 
interest  and  a  perceived  expertise.  Usually  an  industry  trade  group  or  association  of  industry  experts  or  participants, 
the  AO  often  has  extant  standards  that  are  based  on  the  methodologies  of  its  profession  or  discipline  [Cargill  1989, 
105],  The  IEEE  Computer  Society  is  an  exanple  of  an  AO. 

The  ASC  takes  groups  and  factions  with  diverse,  even  antagonistic  viewpoints  and  melds  them  into  a 
semicohesive  whole,  with  the  aim  of  engineering  a  solution  that  encompasses  all  of  the  diversity  while  maintaining 
the  benefits  of  individuality.  The  key  to  the  ASC  is  the  Secretariat,  held  by  a  sponsoring  organization,  which 
provides  legal,  administrative,  and  financial  backing  [Cargill  1989, 107].  The  Computer  and  Business  Equipment 
Manufacturers  Association  (CBEMA)  is  the  Secretariat  for  ASC  X3  on  Information  Processing  Systems  standards. 
In  addition  to  developing,  reviewing,  and  approving  proposed  American  National  Standards,  the  ASCs  coordinate 
standardization  activities  on  the  international  level  by  participating  in  the  ISO. 

The  National  Computer  Systems  Laboratory  (NCSL)  at  the  NIST  contributes  to  the  development  of 
industry-wide  standards  by  leading  and  participating  in  the  work  of  organizations  such  as  ANSI,  IEEE,  and  ISO.  In 
addition  it  develops  tests  and  test  methods  for  new  standards.  NIST  prepares  and  the  Department  of  Commerce  issues 
Federal  Information  Processing  Standards  Publications  (FIPS  PUBS).  Wherever  possible,  the  FIPS  are  aligned  with 
or  identical  to  ANSI  or  ISO  standards.  However,  when  the  government  needs  a  standard,  and  the  industry  and  its 
standards  groups  do  not  respond  to  this  need,  the  NCSL  has  the  ability  to  develop  its  own  FIPS  [Cargill  1989, 213]. 

The  Department  of  Defense  (DoD)  also  issues  standards,  called  MIL-STDs  or  DoD-STDs,  through  its 
Quality  Standardization  Program.  Where  there  is  no  substantial  or  demonstrable  advantage  to  DoD  in  the 
development  of  a  new  standard,  noo-Government  specifications  and  standards  are  to  be  adopted  [DoD  1976,  p2].  The 
DISA  is  responsible  for  developing  military  standards  in  communications  and  information  technology. 

The  Center  for  Information  Management  (CIM)  Infrastructure  office  within  DISA  has  the  responsibility  for 
defining  requirements  and  priorities  for  standards  development  The  Data  Communications  Protocol  Standards 
(DCPS)  Technical  Management  Panel  (DTMP)  [formerly  the  Protocol  Standards  Technical  Panel  (PS TP)]  was 
formed  under  the  direction  of  the  PSSG  to  investigate  technical  matters  and  develop  recommendations  for 
standardization. 

Now  a  part  of  DISA,  the  JIEO  is  the  lead  agency  for  tactical  communications  standards.  The  Center  far 
Standards  centralizes  the  standards  activity  of  DISA.  The  Joint  Message  Standards  Working  Group  (JMSWG)  is 
responsible  for  Joint  Interoperability  Tactical  Command  and  Control  System  (JINTACCS)  message  text  formats 
(MTFs)  and  tactical  data  links.  The  Joint  Technical  Standards  Steering  Group  (JTSSG)  sets  policy  for  and  approves 
the  products  of  the  MIL-STD-187  and  MIL-STD-188  series  standards  activities. 

4.9  Standards  Bodies  in  Non-NATO  Nations 

Finland  is  represented  in  ISO  and  IEC  by  the  Suomen  Standardisoimisliitto  (SFS). 

Sweden  is  represented  in  ISO  by  the  Standardiseringskommisionen  i  Sverige  (SIS).  SIS  coordinates  with 
the  Swedish  Electrical  Commission  (SEK)  and  the  Swedish  Mechanical  Standardization  (SMS). 

The  Irish  member  of  ISO  and  CEN  is  tbe  National  Standards  Authority  of  Ireland  (NSAI),  an  autonomous 
unit  of  tbe  Institute  for  Industrial  Research  and  Standards  (HRS). 

The  Japanese  Industrial  Standards  Committee  (JISC)  oversees  the  Japanese  Industrial  Standards  (JISs).  The 
JISC  is  attached  to  tbe  Agency  of  Industrial  Science  and  Technology,  Ministry  of  International  Trade  and  Industry 
(MITT).  JISC  members  include  representatives  from  manufacturers,  consumers,  and  knowledgeable  individuals. 
Texts  of  standards  approved  by  tbe  relevant  Minister  and  announced  in  tbe  Government  Gazette  are  published  by  the 
Japanese  Standards  Association  (JSA).  An  Information  Technology  Standardization  Technology  Committee 
(INSTAC)  within  the  Japanese  Standards  Association,  the  Telecommunications  Technology  Committee  (TTC),  the 
Interoperability  Database  System  Development  Project,  and  the  Interoperability  Association  for  Information 
Processing  (INTAP)  were  established  in  1985  to  promote  interoperability  technology.  INTAP  has  tbe  responsibility 
to  develop  functional  standards  and  conformance  tests  for  OSI  in  Japan. 

The  Saudi  Arabian  Standards  Organization  (S  ASO)  represents  Saudi  Arabia  in  ISO  and  IEC. 
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STATUS  OF  OPEN  SYSTEMS  STANDARDS 
DEVELOPMENT  IN  ISO/IEC1 


1 .  INTRODUCTION 

This  appendix  provides  an  overview  of  the  work  plans  of  selected  technical  committees  and  working  groups 
in  ISO/IEC  as  well  as  the  work  plan  for  ITU-TS  SG7.  The  purpose  is  to  illustrate  bow  rapidly  international  civil 
standards  are  being  progressed  in  those  areas  applicable  to  automated  information  systems.  A  compilation  of 
ISO/IEC  and  ITU-TS  standards  is  provided  in  Appendix  D  (by  layer  of  the  OSI  Reference  Model)  and  Appendix  E 
(numerical  listing).  An  overview  of  international  standards  bodies  and  their  responsibilities  for  standards 
development  is  provided  in  Appendix  F.  The  information  in  this  Appendix  is  as  of  November  1993. 

2.  STANDARDIZATION  QUESTIONS  FOR  SC21  WORKING  GROUPS2 

Working  groups  in  SC21  address  new  standardization  topics  through  a  series  of  questions,  some  of  which 
are  dosed  by  subsequent  study  and  others  lead  to  new  work  item  proposals.  Listed  below  are  the  open  and  recently 
dosed  questions.  The  digit  following  the  letter  “Q”  indicates  the  working  group  that  originated  the  question.  Thus 
Q  1/17.2  is  the  seventeenth  question  (Subdivision  2)  from  SC21/WG1. 

•  WG1  Questions  an  OSI  Architecture 

Q  1/17.2  Maintenance  of  list  of  definitions  collected  in  OSI  standards  and  draft  standards 

•  Q  1/29  Upper  layer  architecture  coordination  (no  current  work) 

Q  1/30  Lower  layer  inchilccture  coordination  (no  current  work) 

Q  1/41  OSI  management  architecture  coordination  (no  current  work) 

-  Q  1/48.6  LOTOS  enhancements  [SC21N  7096,  draft  answer] 

Q  1/49.8  Conformance  and  registration  [SC21 N  8007,  final  answer] 

Q  1/49.9  Long-term  solution  on  general  and  dependent  conformance  [SC21  N  8008.  final 
answer] 

•  Q  1/53.1  Work  on  security  in  SC21  [SC21 N  3267.  draft  answer] 

Q  1/54  Multipeer  data  transmission  coordination 

Q  1/63.2  Testability  of  managed  objects  [SC21 N  8009,  draft  answer] 

Q  1/65.1  User  requirements  for  OSI  systems  supporting  time  critical  communications 
Q  1/65.2  OSI  protocol  efficiency 

•  Q  1/66  ODP  conformance  testing  methodology 

Q  1/67  Generalization  of  application  service  object  (ASO)  concepts 

Q  1/68  Definition  of  the  term  “ application  process  title”  in  the  OSI  Reference  Model 
[SC21 N  7990,  final  answer] 

Q  1/69  Conformance  assessment  for  OSI  security 
Q  1/70  Clarification  of  the  use  ofNIL  selectors  [SC21N  8001,.  draft  answer] 

Q  1/71  Combined  test  purposes 

•  WG3  Questions  on  Database 

Q  3/001  Support  for  objects  in  database  [SC21N  7180,  draft  answer] 

Q  3/002  Test  embedded  in  structured  databases 

Q  3/003  Interpretation  of  expression  evaluation  (question  closed;  incorporated  m  DIS  9075) 

Q  3/004  Read-only  cursors  (questioo  dosed;  incorporated  in  DIS  9075) 

Q  3/005  Semantics  of  working  view  tables  (question  closed;  incorporated  in  DIS  9075) 

Q  3/006  Module  authorization  identifiers  (question  dosed;  incorporated  fat  DB  9075) 

Q  3/007  Distributed  database  systems 

Q  3/008  IRDS  definition-level  content  standards  for  semantic  unification  meta  model 
(SUMM)  (questioo  withdrawn  June  1993) 

Q  3/009  Approach  to  remote  IRDS  access  [SC21 N  7181,  draft  answer] 

Q  3/010  ODP  md  distributed  database  systems 


1  Ibis  Appaodix  was  updated  from  ISO/IEC  JTC1/SC2I  Program me  of  Work,  Novembar  1993  [SC21  SD-2). 

2  Updated  Fabraary  1994  basad  on  [DRA  1994],  January  1994,  and  Status  Report  on  ITU-TS  Study  Grom  Activities 
(SC21  N  6956],  Jana  1992. 
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Q  3/D  11  Harmonization  of  client  server  capabilities 
Q  3/012  Bole  object  type  taxonomic*  for  IRDS 

•  WG4  Questions  oo  OSI  Management 

Q  4/001  OSI  Software  management  (question  dosed) 

Q4/0Q2  Access  to  distributed  Directory  information  by  a  single  name  (SC21  N  7935,  draft 

Q  4/003  Directory  APIs  (failed  registration  balkx) 

Q  4/004  Directory  schema  migration  [SC21 N  7934,  draft  answer] 

•  WG7  Questions  on  Open  Distributed  Processing 

-  Q  7/001  Ute  of  Z  in  ODP  [SC21 N  7051,  draft  answer] 

•  W08  Questions  oo  OSI  Upper  Layers 

Q  8/001  Versions  six)  extensibility  [SC21 N  7909,  daft  answer] 

Q  8/002  Relationship  between  ULA  and  (XX*  [SC21 N  7910,  find  answer]. 

Study  questions  of  the  TTU-TS  SG7  on  Data  Networks  and  Open  System  Communications  for  the  1993- 
1996  study  period  are  the  following: 

•  Q 1/7,  Standardization  of  the  technical  characteristics  of  international  data  transmission  services,  user 
classes  of  service,  optional  user  facilities,  and  call  progress  signals  in  public  dam  networks  (PDNi) 
and  ISDNs  and  the  categories  of  access  far  DTEs  to  such  services 

•  Q  2/7,  Network  Performance  and  Quality  of  Service  in  Data  Communication  Networks 

•  Q  3/7,  Numbering  Plan  for  Public  Data  Networks 

•  Q  4/7,  Routing  Principles  for  Public  Data  Networks 

•  Q  S/7,  Multicast 

•  Q  6/7,  Rather  study  of  interworking  cases  specific  to  public  data  networks 

•  Q  7/7,  farther  study  of  the  DTE/DCE  interfaces  for  packet-mode  data  terminal  equipments 

•  Q8/7,  Study  of  DTC/DCE  interface  procedures  for  Dissimilar  Terminal  Interworking 

•  Q  9/7,  Racket  nnxle  signalling  between  poblic  networks  providfog  data  transmission  service 

•  Q IOTJ,  Requirements,  arrangements  and  interface  characteristics  for  the  provision  of  data  services,  in 
PSDNs  when  accessed  via  the  ISDNs,  and  ht  ISDNs 

•  Q  11/7,  Principles  of  management  for  public  data  networks  and  for  the  Customer  Network 
Management  Service 

•  Q 12/7,  Management  aspects  of  interworking  between  public  data  networks  td  between  public  data 
networks  and  other  networks 

•  Q 13/7,  Open  Systems  Interoormectioa  (OSD  Systems  Management 

•  Q 14/7,  Message  Handling  Systems  (MHS) 

•  Q 15/7,  Directory  Systems 

•  Q 16/7,  Reference  Model  and  Components  for  Open  Distributed  Processing 

•  Q  17/7,  Tearing  of  Datt  Communication  Protocols 

•  Q 18/7,  X.400/X.500  Conformance  Testing 

•  Q 19/7,  Open  Systems  Interconnect  too  (OSI)  Architecture 

•  Q  2(V7.  Security  services,  mechanisms  and  protocols  for  ITU-TS  applications 

•  Q21/7,  Open  Systems  Interconnection  (OSI)  Application  Layer 

•  Q  22/7,  Open  Systems  Interconnection  (OSI)  Presentation  and  Session  Layers 

•  Q  23/7,  Open  Systems  Intercoonectioo  (OSI)  Transport  and  Network  Layers 

•  Q  24/7,  Open  Systems  Intercoonection  (OSI)  Data  Link  and  Physical  Layers 

•  Q  25/7,  Revision  of  Recommendations. 

3.  INFORMATION  PROCESSING  STANDARDS  (JTC1) 

Tables  G-l  to  G-5  provide3  an  overview 'of  the  work  plans  for  the  major  working  groups  of  ISO/IEC 
JTC1/SC21,  whose  responsibility  is  Information  Retrieval,  Transfer,  and  Management  for  OSL  The  standards 
bodies  indoded  in  this  table  ate: 

•  WG1  on  OSI  Architecture 

•  WG3  on  Database 


3  Thaaa  tables  ara  bmd  on  a  format  development  by  Technology  Appraisals,  n—ifd  The  original  versions  of  the 
(■Mas  warn  taken  from  "Standard  Statui-SC21  Information  Retrieval,  Transfer,  and  Management  of  OST  [Ref. 
rijVM  ItH  wun  paymwnoc).  idb  miaou  wisd  to  aCKB0WM|t  nwiiwom  vjuuviduuobb  non  Aim  riyios  mo 
Technology  Appraisals,  Limited,  during  the  yean  1919-1994. 
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•  WG4  on  OSI  Management  and  OSI  Directory 

•  WG7  on  Open  Distributed  Processmg4 

•  WG8  oo  OSI  Upper  Layers  (formerly  WGS  on  Specific  Application  Services  and  Protocols  and  WG6 
on  Session,  Presentation,  Common  Application  Service  Elements,  and  Upper  Layer  Architecture) 

•  WG  9  on  Testing 

The  symbols  used  in  Tables  G-l  to  G-5  show  the  progress  of  a  standard  from  its  snbmhtinn  as  a  waricing 
draft  (circulated  to  SC21),  through  the  intermediate  stages  of  committee  draft  (CD)  or  draft  proposal  (DP)  and  draft 
international  standard  (DIS),  in  becoming  an  international  standard.  The  position  of  each  symbol  indicates  the 
approximate  time  of  year  the  milestone  represented  by  the  symbol  is  expected  to  occur.  No  symbols  are  used  for 
those  standards  that  reached  IS  status  in  years  prior  to  1993. 
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Table  04.  Statue  of  Standarda  Development  in  ISO/IEC  JTC1  SC21/WQ4 
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Tabla  <5-5.  Status  of  Standards  Davalopmant  In  ISO/IEC  JTC1  SC21/WG8  (Cont'd) 
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APPENDIX  H 


INTERNATIONAL  MILITARY  AND  OTHER 
STANDARDS  BASED  ON  OSI  STANDARDS  OR  USED  IN  OPEN 

SYSTEMS  PROFILES 


I.  NATO  Standards 

II.  National  Military  Standards 

III.  Agraamsnta  from  Rational  Workshops 

IV.  National  Standards  and  Papors 


UNCLASSIFIED 
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INTERNATIONAL  MILITARY  AND  OTHER  STANDARDS 
BASED  ON  OSI  STANDARDS 
OR  USED  IN  OPEN  SYSTEMS  PROFILES 


L  NATO  STANDARDS 


A.  OSI  ST  AN  AGs1 


STANXG  4250* 2 
STANAO  4250-1* 

STANAO  4290-13 

STANAO  4250-2* 

STANAO  4250-3* 

STANAO  4250-4* 

STANAO  4230-5X* 
STANAO  4250-5Y 

STANAO  42304SX 

STANAO  42SU 

STANAO  4232* 

STANAO  4253* 

STANAO  4354* 

STANAO  4255* 

STANAO  4336* 

STANAO  4857* 


NATO  Reference  Model  for  OSI,  Edition  2,  MAS/212-EL/4250,  Military  Agency  for 
Standardization.  21  August  1990  (ratified  md  promulgated),  NATO  UNCLASSIFIED  (cf.  ISO  7499) 
NATO  Reference  Model  for  OSI,  Part  1 -General  Description,  Edition  2  of  STANAO  4250, 
MAS/212-EL/4250,  TSGCE  SQ9, 21  Angoat  1990  (ratified  and  promulgated),  NATO  UNCLASSIFIED 
(cf.  ISO  7498-1) 

NATO  Reference  Model  for  Open  Systems  Interconnection,  Part  1— Basic  Reference  Model, 
Edition  3  of  STANAO  4230,  Draft,  DS(CCC-ICP)(93)703  (distributed  for  staffing),  SG9/WG6, 
11  November  1993,  NATO  UNCLASSIFIED  (work  to  include  ISDN  Reference  Model  in  STANAO 
4230  and  retitle  Part  1  as  NATO  Reference  Model  for  Open  Systems  Information  Exchange  was 
tnepanded  since  agreement  was  not  readied  in  TSGCE  SG9  in  October  1993) 

NATO  Reference  Model  for  OSL  Pat  2-Security,  Draft,  Version  4.0,  December  1993  (eobanitted  for 
■toWl1  final  editing,  and  translation  prior  to  distribution  for  ratification).  NATO  SECRET  (cf.  ISO 
7498-2) 

NATO  Reference  Model  for  OSL  Part  3 -Naming  and  Addressing.  Draft,  DS(CCC-ICP)(93)1 17 
(distributed  for  staffing)  and  AC/302-D/647  (distributed  for  ratification).  12  Match  1993.  NATO 
UNCLASSIFIED  (cf.  ISO  7498-3)  (as  of  23  January  1994.  ratified  by  four  nations) 

NATO  Reference  Model  for  OSL  Part  4-Management,  Draft.  DS(CCC-1CP)(93)1129  (distributed  for 
staffing)  and  AC/302-D/648  (distributed  for  ratification).  26  April  1993,  NATO  UNCLASSIFIED  (cf. 
ISO  7498-4,  10040)  (as  of  23  January  1994,  ratified  by  four  nations) 

NATO  Reference  Model  for  OSI,  Part  5X -Military  Factors.  Draft  (prehminay),  1992.  NATO 
UNCLASSIFIED  (submitted  as  Part  5;  cancelled  May  1993) 

NATO  Refcrooce  Modal  for  OSL  Part  5Y — NATO- Adopted  Civil  Standards,  Draft  (preliminary), 
October  1993,  NATO  UNCLASSIFIED  (submitted  as  Part  S;  wok  suspended  by  action  of  TSGCE  SQ9 
in  October  1993) 

NATO  Reference  Model  for  OSL  Part  6X-NSP  Guidelines,  Draft  (preliminary).  1992.  NATO 
UNCLASSIFIED  [submitted  as  Part  6;  rejected  by  TSGCE  SG9  plenary  in  December  1992  and 
cancelled  in  May  1993;  when  this  document  becomes  stable  (sometime  in  1994),  it  will  be 
subsumed  into  the  NOSIP  Strategy] 

NATO  Reference  Model  for  OSI  •  Layer  1  (Physical  Layer)  Service  Definition.  Draft, 
DS(CCC-ICPX93)123  (distributed  for  staffing.  17  M«h  1993)  md  AC/302-IV649  (distributed  for 
ratification),  30  April  1993.  NATO  UNCLASSIFIED  (cf.  ISO  10731.  10022) 

..NATO  Reference  Modal  for  OSI  •  Layer  2  (Data  Link  Layer)  Service  Definition,  Draft, 
DS(CCC-ICPX93)130  (distributed  for  staffing.  18  Mach  1993)  and  AC/302 -D-6S1  (distributed  for 
ratification),  26  March  1993,  NATO  UNCLASSIFIED  (cf.  ISO  10731. 8886-3) 

NATO  Reference  Model  for  OSI  -  Layer  3  (Network  Layer)  Service  Definition.  Draft, 
DS(CGC-ICP)(93)166  (distributed  for  staffing;  awaiting  electronic  copy  and  copies  of  referenced 
ISO  standards  before  final  translation  can  be  completed),  18  March  1993.  NATO  UNCLASSIFIED 
(Appendix  B  is  NATO  CONFIDENTIAL)  (cf.  ISO  10731,  S348/AD2) 

NATO  Reference  Model  for  OSI  •  Layer  4  (Transport  Layer)  Service  Definition,  Draft, 
DS(CCC-ICP)(93)168  (distributed  for  staffing;  awaiting  copies  of  referenced  ISO  standards  before 
final  translation  can  be  completed),  19  March  1993,  NATO  UNCLASSIFIED  (cf.  ISO  10731, 8072) 
NATO  Reference  Model  for  OSI  -  Layer  5  (Session  Layer)  Service  Definition.  MAS/D4-EL/4235, 
Military  Agency  for  Standardization,  22  January  1993  (ratified  and  promulgated),  NATO 
UNCLASSIFIED  (cf.  ISO  10731,  8326) 

NATO  Reference  Model  for  OSI  •  Layer  6  (Presentation  Layer)  Service  Definition, 
M AS/04- EL/4256,  MiliUry  Agency  for  Standardization,  22  January  1993  (ratified  and 
promulgated),  NATO  UNCLASSIFIED  (cf.  ISO  10731, 8822, 8823) 

NATO  Reference  Model  for  OSI  •  Layer  7  (Application  Layer)  Service  Definition,  Draft, 
DS(CCC-ICPX93)174  (distributed  for  staffing,  19  Mach  1993)  md  AC/302-D/657  (dist  ibuted  for 


*  Statne  from  NATO  International  Military  Staff  as  provided  in  5-6  May  1993  Sdbgroap  9  Coordination  Meeting, 
HBO/TBBD,  13  May  1993  and  [Rmneatad  1994b],  23  Jaauay  1994. 

2  TBs  symbol  •  identifies  standards  listed  in  the  base  standards  of  the  1993  NOSIP  Strategy. 
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UNCLASSIFIED 


UNCLASSIFIED 


< 


STANAG  4258* 
STAN  AG  4259* 
STANAG  426 U 

STANAG  4262* 

STANAG  4263* 

STANAG  4264* 

STANAG  4265* 

STANAG  4266* 

STANAG  4267* 

STANAG  4406* 


STANAG  4407* 


STANAG  4408* 


STANAG  4409* 


ratification),  11  November  1993.  NATO  UNCLASSIFIED  (cf.  ISO  10731,  8649,  8649/AMI. 
9066-1.  9072-1) 

Specification  of  ASN.l.  MAS/04-EL/4258,  Military  Agency  for  Standardization.  22  January  1993 
(ratified  and  promulgated).  NATO  UNCLASSIFIED  (cf.  ISO  8824) 

Specification  of  Basic  Encoding  Rules  for  ASN.l,  MAS/04-EL/4259,  Military  Agency  for 
Standardization,  21  January  1993  (ratified  and  promulgated),  NATO  UNCLASSIFIED  (cf.  ISO  8825) 
NATO  Reference  Model  for  OSI  -  Layer  1  (Physical  Layer)  Protocol  Specification,  Draft, 
DS(CCC-ICPX93)129  (distributed  for  staffing;  awaiting  copies  of  referenced  ISO  standards  before 
final  translation  can  be  completed),  17  March  1993,  NATO  UNCLASSIFIED 
NATO  Reference  Model  for  OSI  -  Layer  2  (Data  Link  Layer)  Protocol  Specification,  Draft, 
DS(CCC-ICPX93)128  (distributed  for  staffing,  18  March  1993)  and  AC/302-D/652  (distributed  for 
ratification),  26  Match  1993,  NATO  UNCLASSIFIED  (cf.  ISO  7776,  8802-2,  8802-3,  8802-5) 
NATO  Reference  Model  for  OSI  -  Layer  3  (Network  Layer)  Protocol  Specification,  Draft, 
DS(COC-ICPX93)167  (distributed  for  staffing;  awaiting  electronic  copy  copies  of  referenced  ISO 
standards  before  final  translation  can  be  completed),  19  March  1993,  NATO  UNCLASSIFIED  (cf. 
ISO  8208,  8473,  8648,  8878,  8880-1,  8880-2,  8880-3,  8880-4,  9542,  11577,  X.25) 

NATO  Reference  Model  for  OSI  -  Layer  4  (Transport  Layer)  Protocol  Specification,  Draft, 
DS(CCC-ICPX93)172  (distributed  for  staffing;  awaiting  electronic  copy  copies  of  referenced  ISO 
standards  before  final  translation  can  be  completed),  19  March  1993  ,  NATO  UNCLASSIFIED  (cf. 
ISO  8073,  8073/AD2,  8073/DAM3,  8602) 

NATO  Reference  Model  for  OSI  -  Layer  5  (Session  Layer)  Protocol  Specification,  M AS/04- EL/4265, 
Military  Agency  for  Standardization.  22  January  1993  (ratified  and  promulgated),  NATO 
UNCLASSIFIED  (cf.  ISO  8327,  8327-2) 

NATO  Reference  Model  for  OSI  -  Layer  6  (Presentation  Layer)  Protocol  Specification, 
MAS/04-EL/4266,  Military  Agency  for  Standardization,  22  January  1993  (ratified  and 
promulgated),  NATO  UNCLASSIFIED  (cf.  ISO  8822, 8823) 

NATO  Reference  Model  for  OSI  -  Layer  7  (Application  Layer)  Protocol  Specification,  Draft, 
DS(CCC-ICPX93)175  (distributed  for  staffing,  22  March  1993)  and  AC/302-D/658  (distributed  for 
ratification),  25  November  1993,  NATO  UNCLASSIFIED  (cf.  ISO  8650.  8650/AMI.  9066-2. 9072- 
2)) 

NATO  Reference  Model  for  OSI  -  Military  Message  Handling  System,  Draft  (in  final  editing), 
DS(CCC-ICPX93)161  (distributed  for  staffing,  17  March  1993)  and  AC/302(SG/9)WP/33, 
26  November  1993,  NATO  UNCLASSIFIED  (cf.  ISO  10021,  10611)  (a  revised  draft  that  includes 
Annex  D  is  planned  for  SG9  staffing  in  October  1994) 

Main  Body,  Draft 

Annex  A — MMHS  Extensions  to  ISO  10021  Series,  Draft 
Annex  B — Security  Aspects  of  MMHS  (under  development) 

Annex  C — Alpha  Profile  Set  (a  delta  specification  to  EWOS  profiles):  AMHlx(M)  on  Common 
Facilities  and  AMH9x(M)  on  Military  Messaging,  Draft 
Annex  D — Alpha/ACP  127  Gateway  (under  development) 

Annex  E — Alpha/MMHS(84)  Gateway  (under  development) 

Annex  F — Alpha/MHS(88)  Gateway  (under  development) 

Annex  G — Beta  Profile  Set  (under  development) 

Annex  H — Bcta/ACP  127  Gateway  (under  development) 

Annex  I— Beta/Alpha  Gateway  (under  development) 

NATO  Reference  Model  for  OSI  -  Systems  Management,  Draft.  DS(CCC-ICPX93)158  (distributed  for 
staffing;  awaiting  copies  of  referenced  ISO  standards  before  final  translation  can  be  completed), 
15  May  1993,  NATO  UNCLASSIFIED  (cf.  ISO  10165-1,  10165-2,  10165-4,  10164,  11183. 
12059,  12060) 

Mam  Body,  Preliminary  Draft 

Annex  A — Security  of  Management  (under  development) 

Annex  B — Military  Features,  Preliminary  Draft 

Annex  C— ' The  Development  of  NSPs  for  Systems  Management,  Preliminary  Draft 
Annex  D — NSP  zzzz:  Basic  Systems  Management ,  Preliminary  Draft  (STANAG  4407-1) 

NATO  Standardized  Profile  TAdnno(M)  -  Connection-mode  Transport  Service  over  Connectionless¬ 
mode  Network  Service,  Draft,  October  1993,  NATO  UNCLASSIFIED  (to  be  distributed  to  the 
nations;  following  agreement  and  receipt  of  copies  of  referenced  ISO  standards,  final  editing  and 
translation  precedes  distribution  for  ratification) 

Part  1:  Subnetwork  Type  Independent  Requirement*  for  Group  TA  Draft  (cf.  ISO  10608-1) 

Part  2:  TA5o(M)  Subnetwork  Type  Independent  Requirements  for  LANs,  Draft  (cf .  ISO  10608-2) 
Part  3:  TA51(M)  Profile  -  CSMA/CD  LAN  Requirement*,  Draft  (cf.  ISO  10608-2) 

Part  4:  TA54(M)  Profile  -  Fiber  Distributed  Data  Interface  (FDDI)  LAN  (Military)  Requirements, 
Draft  (cf.  ISO  10608-6) 

NATO  Standardized  Profile  -  Connection-mode  Transport  Service  over  Connection-mode  Network 
Service  (Military),  Draft,  DS(CCC-ICP)(93)231  (distributed  for  staffing;  awaiting  copies  of 
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UNCLASSIFIED 


Military  Standards 


UNCLASSIFIED 


STANAQ  4410* 


STANAG  4413* 


STANAQ  4459* 


STANAQ  4440* 


STANAQ  4461* 


STANAQ  4462* 


STANAG  4463* 


STANAG  4464* 

STANAG  44/55* 
STANAG  4466* 
STANAQ  4467* 
STANAG  4468* 


referenced  ISO  standards  before  final  translation  can  be  completed),  7  April  1993,  NATO 
UNCLASSIFIED 

Part  1:  Definition  of  Profiles  TCll  1  l(MyTCl  121(M),  Draft  (cf.  ISO  10609-6) 

Part  2:  Subnetwork-Type  Independent  Requirements  for  Group  TC,  Draft  (cf.  ISO  10609-2) 

Part  3:  Subnetwork  Type  Dependent  Requirements  for  Permanent  Access  to  a  Packet  Switched  Data 
Network  Using  Virtual  Call,  Draft  (cf.  ISO  10609-9) 

NATO  Standardized  Profile  -  Connectionless-mode  Transport  Service  over  Connectionless-mode 
Network  Service,  Draft,  DS(CCC-ICPX93)232  (distributed  for  staffing;  awaiting  electronic  copy 
copies  of  referenced  ISO  standards  before  final  translation  can  be  completed),  7  April  1993,  NATO 
UNCLASSIFIED 

Part  1;  Subnetwork -Type  Independent  Requirements  for  Group  UA,  Preliminary  Draft 

NATO  Standardized  Profile  -  Relaying  the  Connectionless-mode  Network  Servioe 

Part  1:  Subnetwork-Type  Independent  Requirements  for  Group  RA,  Edition  2.  January  1993  (cf. 

ISO  10613-1)  (under  development) 

Part  2:  Subnetwork-Type  Dependent,  Media  Independent  Requirements  for  LANs,  Edition  2, 
January  1993  (cf.  ISO  10613-2)  (under  development) 

Part  3:  ISDN  Subnetwork-Dependent,  Media-Dependent  Requirements  for  Circuit-Switched 
B -Channel  Operation,  Edition  2,  January  1993  (under  development) 

Part  4:  Profile  RA5 1.4212,  Edition  2,  January  1993  (under  development) 

ISDN  Bearer  Services,  Draft  (in  final  approval  prior  to  submission  for  translation  and  ratification), 
DS(CCC-ICPX93)233  (distributed  for  staffing,  7  April  1993)  and  AC/302-D/659  (distributed  for 
ratification),  9  June  1993,  NATO  UNCLASSIFIED  (cf.  L230) 

Layer  1  Specifications  for  ISDN  Basic  Rate  Access  at  the  S/T  Reference  Point,  Draft  (in  final 
approval  prior  to  submission  for  translation  and  ratification),  DS(CCC-1CPX93)234  (distributed  for 
staffing,  8  April  1993)  and  AC/302-D/660  (distributed  for  ratification),  9  June  1993,  NATO 
UNCLASSIFIED  (a  second  version  is  under  development) 

Layer  1  Specifications  for  ISDN  Primary  Rate  Access  at  the  S/T  Reference  Point,  Draft  (in  final 
approval  prior  to  submission  for  translation  and  ratification).  DS(CCC-ICP)(93)235  (distributed  for 
staffing,  8  April  1993)  and  AC/302-D/661  (distributed  for  ratification).  9  June  1993,  NATO 
UNCLASSIFIED  (a  second  version  is  under  development) 

Layer  2  Specifications  for  ISDN  Basic  and  Primary  Rate  Access  at  the  S/T  Reference  Point,  Draft  (in 
final  approval  prior  to  submission  for  translation  and  ratification),  DS(CCC-ICPX93)236 
(distributed  for  staffing,  8  April  1993)  and  AC/302-D/662  (distributed  for  ratification), 
9  June  1993,  NATO  UNCLASSIFIED  (a  second  version  is  under  development) 

Layer  3  User  to  Network  Call  Control,  Draft,  DS(CCC-ICPX93)237  (distributed  for  staffing). 
8  April  1993,  NATO  UNCLASSIFIED  (to  be  distributed  for  ratification  as  soon  as  the  translation  is 
completed;  a  second  version  is  under  development) 

Signalling  System  No.  7  Message  Transfer  Part  (MTP),  Draft  (to  be  distributed  to  the  nations; 
following  agreement,  final  editing,  and  translation,  to  be  distributed  for  ratification) 

Signalling  System  No.  7  ISDN  User  Part  (IS UP)  (under  development) 

ISDN  Teleservices  (under  development) 

ISDN  Supplementary  Services  (under  development) 

QSIG  (under  development) 


B.  OTHER  STANAG*  AND  AGREEMENTS3 


AAP-3 


AAP-4 

AAP-7 


AAP-6(Q) 

AAP-15(D) 

ACP121 

ACP123 

ACP  126 

ACP  127 

ACP-167(F) 

AD*tP-2(D) 

ADatP-3 


ADatP-11 


Procedures  for  the  Development,  Preparation,  Production  and  the  Updating  of  NATO  Standardization 
Agreeements  (STANAGs)  and  Allied  Publications  (APS) 

NATO  Standardization  Agreeements  and  Allied  Publications 

Allied  Maritime  Structures  Messages,  Military  Agency  for  Standardizaton  (see  STANAGs 
1020-1370) 

NATO  Glossary  of  Terms  and  Definitions  for  Military  Use,  Revision  Q 
Glossary  of  Abbreviations  Use  in  NATO  Documents,  Revision  D,  September  1990 
Communications  Instructions  -  General 

Communications  Instructions  -  fommon  Messaging  Strategy  and  Procedures,  Draft,  February  1993 
Communication  Instructions  -  Tele  type  wrirer/Teleprinter  Procedures 
Communication  Instructions  -  Tape  Relay  Procedure* 

Glossary  of  COmmunications-Electronics  Terms,  Revision  F 

NATO  Glossary  of  Automatic  Data  Processing  (ADP)  Terms  and  Definitions,  Revision  D 

NATO  Message  Text  Formatting  System  (FORMETS),  ADSIA  WG5  (see  STANAGs  5500, 5620,  md 

5621;  and  ACP  127) 

Standard  Operating  Procedures  for  NATO  Link  11,  ADISA  WG1 


3  Revised  bassed  on  [NIPD  1993,  Volume  VI]  and  [NATO  1993], 
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UNCLASSIFIED 


UNCLASSIFIED 


AM-11  Standard  Operating  Procedures  for  be  ShipfSbon/Sbip  Buffer,  ADISA  W04 

ADetf-14  Stanched  Operating  Procedune  for  NATO  Link  14,  ADISA  WO! 

AIMP-16  Stamhud  Operating  Procedune  for  NATO  Link  16,  ADISA  WG4 

AAP-20  Pbeeed  Annameoti  Prognmmkig  System  (PAPS) 

ADetP-31  Stendeed  Operating  Prooedane  for  NATO  Link  1.  ADISA  WG4 

UMS  DM  Interim  Joint  Tecticel  Information  Diatribution  Syctem  (JTIDS)  Meaaage  Specification* ,  ADSIA 

was 

UMS  D/S  UMS  Implementation  Docnment 

UMS  DM  Standard  Operating  Procedures  for  UMS,  ADSIA  WG4 

STANAG  4146  Interim  Specification*  for  InputAOutput  Interface*  in  NATO  Naval  Data  Handling  Equipment 

STANAG  41S3  Standard  Specification  for  an  Asynchronous  Serial  Data  Interface  for  Point  to  Point  Connection* 

and  for  Connection  to  Data  Network*  in  NATO  Naval  Syctem* 

STANAG  4156  Standard  Specification  for  a  Serial  Data  Interface  for  Syncfaroooo*  Connection*  to  a  Data  Network 

STANAG  4159  NATQO  Materiel  Configuration  Management  Policy 

STANAG  4175  Technical  Characteristic*  of  the  Multi-Functional  Information  Distribution  System  (MDDS),  TSGCE 

SQ9  (complementary  to  STANAG  SS16) 

STANAG  4197  Modulation  and  Coding  Characteristic*  that  must  be  Common  to  Assure  Interoperability  of  2400 

BPS  Linear  Predictive  Encoded  Digital  Speech  Transmitted  Over  HF  Radio  Facilities 
STANAG  419S  Parameter*  and  Coding  Characteristic*  That  Must  Be  Common  to  Assure  Interoperability  of  2400 

BPS  linear  Predictive  Encoded  Digital  Speech 
STANAG  4199  Uuifoaa  System  of  Exchange  of  Materiel  Management  Data 

STANAG  4202  Transmission  Envelope  Characteristics  for  High  Reliability  Data  Exchange  between  Land  Tactical 

Data  Processing  Equipment  Over  Single  Channel  Radio  Link* 

STANAG 4203  Technical  ^tendard*  for  Singh  Bunnell  HF  Partin  Equipment 

STANAG  4204  Technical  Standards  for  Single  Channel  VHP  Radio  Equipment 

STANAG  4205  Technical  Standards  for  Single  UHF  Radio  Equipment 

STANAG  4206  The  NATO  Multichamel  Tactical  Digital  Gateway-System  Standards 

STANAG  4207  Tbs  NATO  Multi-Channel  Tactical  Digital  Gateway  -  Multiplex  Group  Framing  Standards 

STANAG  4208  The  NATO  Multi-Channel  Tactical  Digital  Gateway  -  Signalling  Standards 

STANAG  4209  The  NATO  Mohi -Channel  Tactical  Digital  Gateway  -  Standards  for  Analogue  to  Digital  Conversion 

of  Speech  Signalt 

STANAG  4210  The  NATO  Multi-Channel  Tactical  Digital  Gateway  -  Cable  Link  Standards 

STANAG  4211  The  NATO  Mnlti-Channel  Tactical  Digital  Gateway  -  System  Coatrol  Standards 

STANAG  4212  The  NATO  Multi-Channel  Tactical  Digital  Gateway  -  Ratio  Relay  Link  Standards 

STANAG  4213  The  NATO  Mnlti-Channel  Tactical  Digital  Gateway  -  Data  Transmission  Standards 

STANAG  4214  International  Routing  and  Directory  for  Tactical  Communication  Systems 

STANAG  4231  Digital  Interoperability  Between  UHF  Tactical  Satellite  Comnmnicatione  Terminals 

STANAG  4232  Digital  Interoperability  Between  SHF  Tactical  Satellite  Conununicatione  Terminals 

STANAG  4233  Digital  Interoperability  Between  EHF  Tactical  Satellite  Cnnuimnications  Terminals 

STANAG  4234  Radio  Frequency  Environmental  Conditions  Affecting  the  Design  of  Materiel  for  Use  by  NATO 

Foroe* 

STANAG  4245  Secure  and  ECM  Rsristant  HF  Low  Speed  Digital  Data  Communicatiooi  System 

STANAG  4246  Have  Quick  end  UHF  Secure  Jem  Reeietant  Counmacatiouc  Equipment 

STANAG  4249  NATO  Multi-Channel  Tactical  Digital  Gateway  -  Data  Transmission  Standards  (Packet  Switching 

Service) 

STANAG  4250  The  NATO  Reference  Model  for  Open  Systama  Interconnection  -  Overview 

STANAG  4261  The  NATO  Reference  Model  for  Open  Syatema  Interconnection-  Layer  1  (Physical  Layer)  Protocol 

Specification 

STANAG  4262  The  NATO  Reference  Model  for  Open  Systems  Interconnection  -  Layer  2  (Data  Link  Layer)  Protocol 

Specification 

STANAG  4263  The  NATO  Reference  Model  for  Open  Systems  Interconnection  -  Layer  3  (Network  Layer)  Protocol 

Specification 

STANAG  4271  BCM  Resistant  Digital  Traffic  Exchange  Between  Tactical  Satellite  Communications  Terminals 

STANAG  42S5  Characteristics  of  a  12000400  Bite  Per  Second  Single  Tome  Modulator/Demoduletnr  for  HF  Radio 

Links 

STANAG  4290  NATO  Mnlti-Chtmwl  Tactical  Digital  Gateway  •  Cable  Link  (Optical)  Standsnb 

STANAG  4291  Modulation  and  Coding  Characteristics  that  must  be  Common  To  Assure  Interoperability  of  2400 

BPS  Wireline  Modems  for  Use  in  Nwrow-Baod  Secure  Voice  Systran* 

STANAG  4292  Stamtards  to  Achieve  Communications  Between  Tactical  Combat  Net  Radio  Equipment  Designed  to 

STANAG  4202  end  Ftsquency  Hopping  Radios  Operating  In  the  Same  VHP  Band 
STANAG  4295  Significant  Data  and  Telegraph  Signalling  Condition* 

STANAG  5000  Interoperability  of  Tactical  Digital  Facsimile  Equipment 

STANAG  5004  Military  Characteristics  for  Field  Taiapbooe  Sets  (Minimum  Stmdwd) 

STANAG  5009  (Exact  Title  Unknown  •  Relates  to  Naval  Gunfire  Support  Using  HF  Radio) 

Appendix  H  H-4  Military  Standards 

UNCLASSIFIED 


UNCLASSIFIED 


STAN  AO  5018 

STAN  AO  5020 

STAN  AO  5026 
STANAG  5028 

STAN  AG  5030 
STANAG  5031 
STANAG  5032 
STANAG  5035 
STANAG  5036 
STANAG  5038 
STANAG  5040 


STANAG  5500 
STANAG  5501 
STANAG  5504 
STANAG  5505 
STANAG  5506 
STANAG  5507 
STANAG  5510 
STANAG  5511 
STANAG  5514 
STANAG  5516 
STANAG  5550 
STANAG  5601 

STANAG  5616 

STANAG  5620 
STANAG  5621 
STANAG  5622 
STANAG  5623 


NATO  Manual  Interface  Between  the  Manual  Switched  Telecommunication!  System*  of  the  Combat 
Zone 

Interoperability  of  Aircraft  UHF  Multi-Frequency  Transceiver  Installation  and  Compatible  Ground 
Transmitters  and  Receivers 

Military  Characteristics  for  Facsimile  Equipment  To  Meet  Meteorological  Requirements 
Significant  Telegraph  Signalling  Conditions  in  Automatic  Telegraphy  [Morse  and  International 
Alphabet  (IA)  No.  2] 

Single  and  Multichannel  VLF  and  LF  On-Line  Broadcast  and  Off-Line  OOK  Systems 
Introduction  of  Modem  Audio  Equipment  for  Naval  HF-MF  and  LF  Sbore-to-Ship  Broadcasts 
HF  Single  Sideband  Single  Channel  Voice  Communications  (exact  title  unknown) 

Introduction  of  an  Improved  System  for  Maritime  Air  Communications  on  HF,  LF  and  UHF 
Parameters  and  Practices  for  the  Use  of  the  NATO  7-Bit  Code 
Interoperability  of  Ship  UHF  Transmitting  and  Receiving  Systems 

NATO  Automatic  and  Semi-Automatic  Interfaces  Between  the  National  Switched 
Telecommunication*  Systems  of  the  Combat  Zone  and  Between  These  Systems  and  the  NICS  from 
1979  lo  the  1990‘s 

NATO  Message  Text  Formatting  System  (FORMETS),  ADSIA  WG5  (see  ADatP-3) 

Tactical  Data  Exchange  -  Link  1  (Point-to-Point),  ADISA  WG4 
Tactical  Data  Link  for  the  Control  of  Aircraft  -  Link  4,  ADISA  WG4 
NATO  Standard  Bit  Fields,  Bit  Field  Fillers  and  Codes 
Link  6  SAM/NADGE  Link 

Tactical  Data  Link  for  Air  Traffic  Control  -  Link  7,  ADISA  WG4  (dormant) 

Maritime  Tactical  Data  Exchange  •  Link  10 

Tactical  Data  Exchange  -  Link  1 1  and  Link  11B,  Volumes  I  and  II,  ADISA  WG1 
Tactical  Data  Broadcasting  -  Link  14,  ADISA  WG1 
Tactical  Data  Exchange  -  Link  16.  ADISA  WG4 
NATO  Standard  Data  Elements,  Data  Items  and  Codes 

Standards  for  Interface  of  NATO  Data  Links  1,  11,  14,  and  11B  Through  a  Ship/Shore/Ship  Buffer, 
ADISA  WG4 

Standards  for  Data  Forwarding  Between  Tactical  Data  Systems  Employing  Digital  Data  Link  11/1  IB 
and  Tactical  Data  Systems  Employing  Link  16  (complementary  to  STANAG  4175) 

Standards  for  the  Interoperability  of  ADP  Fire  Support  Systems 

Standards  for  the  Interoperability  of  NATO  Land  Combat  and  Combined  Operations  Systems 
Air  Operations  System 

Standards  for  Interoperability  of  Maritime  Operations  Systems 


C.  OTHER  NATO  DOCUMENTS 

ACP  127  Message  Relay  Procedures 

ACP  167(F)  Glossary  of  Communications-Electronics  Terms,  NATO,  August  1981,  UNCLASSIFIED 

ADatP-2(D)  NATO  Glossary  of  Automatic  Data  Processing  (ADP)  Tents  and  Definitions,  December  1985,  NATO 

UNCLASSIFIED 

ADstP-3  (STANAG  5500)  NATO  Message  Text  Formatting  Systems,  Part  IV,  Catalog  of  Standard  Field  Formats, 
'*  December  1986,  NATO  UNCLASSIFIED 

AM  96-1-4  Data  Management,  SHAPE,  30  October  1988,  NATO  UNCLASSIFIED 

Classification  Guide  NATO  Network  Security  Information  Classification  Guide  (NU),  Version  1.0,  TSGCE  SG9, 
February  1989,  NATO  RESTRICTED 

MC4  203/2  The  Operational  Requirements  for  the  Interoperability  of  the  Communications  Between  Different 

National  Component  Land  Forces  in  the  Combat  Zone  and  the  Communication  Used  in  Provieioo  of 
Air  and  Naval  Support  to  These  Forces 

MC  277  The  Operational  Requirement*  for  the  Interoperability  of  Tactical  Communication  Systems  for  Use 

by  the  NATO  Nations  in  the  Land  Combat  Zone  -  Post  1985 
MC  283  The  Military  Police  for  ECCM  Applied  to  Tactical  Communications  in  the  Combat  Zone 

MC  284  The  NATO  Military  Requirement  for  ECM  Resistant  and  Secure  Communications  (NR) 

NIMP  NATO  Interoperability  Management  Plan  (NIMP),  Third  Endorsement  Edition.  ADSLA-RCU-Dfl 

(Revised),  Allied  Data  Systems  Interoperability  Agency,  1  July  1988,  NATO  UNCLASSIFIED 
NIPDVol.  1  NATO  Interoperability  Planning  Document  (NIPD),  Volume  1,  Introduction  to  Infbnnarion  Systems 

Interoperability  Including  the  Allied  Data  Systems  Interoperability  Agency  and  the  Organization  of 
and  Coordination  Among  NATO  Bodies  Involved  in  NATO  Common  Interoperability  Standards 
Development  and  Configuration  Management,  Second  Draft,  ADSIA-RCA-WP/76,  20  April  1990. 
NATO  UNCLASSIFIED 
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NIPDVoL  2 
NIFDVol.3 

NIPDVol.  4 

NIPDVol.  5 
NIPDVol.  6 

NCSA 

NOSIP  Strategy 


NATO  Interoperability  Planning  Document  (NIPD),  Volume  2,  Formal  Specification  of  Information 
Exchange  Requirements,  Dolt.  ADSIA-RCA-WP/72,  February  1990,  NATO  UNCLASSIFIED 
NATO  Interoperability  Planning  Document  (NIPD).  Volume  3.  Plan  for  Development  of  NATO 
Common  Interoperability  Standards  (NCIS),  Revised  Draft,  ADSIA-RCA-WP/73  (Hrst  Revise), 
February  199a  NATO  UNCLASSIFIED 

NATO  Interoperability  Planning  Document  (NIPD),  Volume  4,  NATO  Common  Interoperability 
Standards  Configuration  Management  Plan  (NCISCMP),  Revised  Draft,  ADSIA-RCA-WP/32 
(5th  Revise),  August  1989,  NATO  UNCLASSIFIED 

NATO  Interoperability  Planning  Document  (NIPD),  Volume  5,  NATO  Common  Interoperability 
Standards  Testing  Concept,  Fust  Draft,  ADSIA-RCA-WP/75,  February  1990,  NATO  UNCLASSIFIED 
NATO  Interoperability  Planning  Document  (NIPD),  Volume  6,  Documentation  Plan  for  NATO 
Common  Interoperability  Standards,  First  Draft,  ADSLA-RCA-D- 15-90,  13  June  1990,  NATO 
UNCLASSIFIED 

NATO  OSI  Security  Architecture  (NOSA),  Ad  Hoc  Working  Group  on  Security,  TSGCE  SG9,  Draft 
Version  2.1,  March  1988,  NATO  UNCLASSIFIED 

NATO  Open  Systems  Interconnection  Profile  (NOSIP)  Strategy,  TSGCE  SG9,  23  September  1993. 
NATO  UNCLASSIFIED 


NI1S  Transition  Strategy  NATO  Technical  Interface  Standards  (NTIS)  Transition  Strategy,  Sixth  Edition,  AC/259- 
D/1218(Revised),  Conference  of  National  Armaments  Director*  (CNAD),  Tri-Service  Group  on 
Communications  and  Electronic  Equipment  (TSGCE),  NATO,  Brussels,  September  1991,  NATO 
UNCLASSIFIED 

SANISI  Security  Architecture  for  NATO  Information  Systems  Interconnection  (SANISI)  (NU),  Version  2.0, 

Ad  Hoc  Working  Group  on  Security,  TSGCE  SG9,  AC/302(SG/9)D/S3.  14  April  1989,  NATO 
CGNHDEN11AL 

STAMINA  4.0  Standard  Automated  Message  Interface  for  NATO  ACCIS  (STAMINA),  Version  4.0,  NACISA, 

April  199a  NATO  UNCLASSIFIED 

TM-776  Data  Management  Standardization  for  ACE  ACCIS,  TM-776,  SHAPE  Technical  Centre,  July  1985, 

NATOUNCLASSHED. 
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UNCLASSIFIED 
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n.  NATIONAL  MILITARY  STANDARDS 


A.  US  DoD  STANDARDS— GENERAL 

DoD-STD-498  Software  Development  Standard  (SDD),  to  be  iaaoad  ia  1994 

DoD-STD-1447  Software  Support  Eovironment,  IS  January  19SS 
DoD-STD-1700  Data  Mwagamwil  Program.  28  September  1987 

DoD-STD-1703  Software  Noduet  Standards,  12  February  1987 

DoD-STD-1838A  Common  Ada  Programming  Support  Environment  (APSE)  Interface  Sot  (CAIS-A),  6  April  1989 
DoD-STD>2167A  Defense  Syatem  Softwere  Development 

MIL-A-99007  Preeentatine  Manager 

IrfLAOQGUDfiA  AcquirittonOulde  for  Implementation  of  Computer-aided  AcgnjalUnn  and  LagMic  Support  (CALS) 

M1L-C-2S74SA  Co  enact  on.  Electrical,  Rectangular.  Reck  and  Panel.  Solder-Type  and  Crimp-Type  Contnete, 

February  1985 

MIL-C-CniS  Contractor  Integrated  Technical  Information  Service  (CTOS),  Fenctkieel  Recpriramente  (Dnil) 

M1L-D-28000A  Digital  Repceeentetion  for  Common icatiofl  of  Product  Data:  KJBS  Application  Subeeta, 
10  February  1992  with  Amendment  1  of  14  December  1992  (need  in  CALS  for  congaf  aided 
design  and  vector  graphics  (e.g.,  in  technical  mannal  Uhmrationa,  anginaaring  dtograms) 
MIL-D-280Q3A  Digital  Rcpccaentatioa  for  Coalman ication  of  Illnatration  Data:  COM  Application  ProfUa, 
15  November  1991.  Amendment  1  it  dated  14  August  1992 
MIL-D-S7269  Interchange  Formats  for  Interactive  Eleetroaie  Technical  Mannal  (IETM)  Databacm 

MIL-D-89000  Digital  Terrain  Elevatioo  Data 

MIL-H3BK-59D  Department  of  Defeaae  Computer-aided  Acquisition  and  Logistic  Support  (CALS)  Progrmn 
Impiamantatjcn  Guide.  12  June  1993 

Mn^HDBK-7596  Human  Factors  Fngineermg  Design  for  Army  Materiel  Metric,  Jws  1992 
M2L-HDBK-761A  Roman  Engineering  Guidelines  for  Managsmeat  Information  Systems,  September  1989 

MIL-HDBK-782  Software  Support  Environment  Acquisition  Implements tioo  Guide  for  DoD-STD-2167, 

29  February  1988 

MIL-HDBK-S29-1  MIL-STD-204S  Series  Documentation,  Voiuma  1,  23  April  1993 

MIL-HD8K-829-2  Gmdslmes  for  Data  Cormnumcations  Protocol  Standwds  (DCPS)  DoD  StadmOaed  Proftlm  (DSPs). 
23  April  1993 

MIL-HDBK-1300  National  Imagery  Trammiaeioo  Format  Standard  (NTIFS),  18  fona  1993 

MIL-M-28Q01B  Mwtap  Rcqubveneati  and  Oerwric  Styk  Specification  for  Electronic  Printed  Oetpnt  md  Brrbw^r  of 
Text  and  Amendment  1, 26  June  1993  (bnmd  on  ISO  8879.  SGML) 

MIL-M-87268  Interactive  Electronic  Technical  Manuals  (IETMs):  General  Cnnlint.  Styia  md  Format 

MIL-Q- 87270  Raquitcmaata  for  Quality  Aaaurance  Programr  for  Inmraciiva  Bactmate  Technical  Ma— la  (lEIMa) 

MIL-R-2S002B  Requirements  for  Raster  Graphics  Representation  in  Binary  Formal.  14  Draanftar  1992  (baaed  on 

GRP  4  Raster  de  facto  iadurtrial  staadndr.  mad  in  CALS  for  Rmltr  trinnid  hnagm  hi  i^lmnlaq 
drawings  and  technical  mannal  Uluatrattom) 

B.  US  DoD  STANDARDS— MIL-STD-2845-SERIES  FOR  DoD  COMMUNICATIONS5 
1999 -8  tries — Physical  Layer 

>888  8 at  lae  Data  Link  Layer 
3888  Sarfee — Network  Layer 

3588-Sertea — Netwnrk/Rclay  Profllee/Mnltl-Layer 

MJL-S1D-1745-13500  Information  Technology  *  Defease  Standardised  Profiles  -  Internet  Relay  Profile  for  DoD 
Communications  -  Point-to- Point  Protocol  (PPP),  Working  Draft,  Draft,  1993 
4888  Series  Transport  Layer 
4S99-8o  rice  Trane  port  Profllee/Mnltl-Layer 

MLrSTD-1745-14500  Reliable  End  System  (ES)  Transport  for  DoD  Commimirntiooa.  Draft.  1993  (approved  by 
DTMP  for  validation) 

MIL-STD-1745-14501  Iaformetiou  Technology  •  Defense  Staadardimd  Nofilm  •  firimlT-  Transport  Profile  (in  SD-1 

coordination5) 

MIL-STD-1745-14502-01  Information  Technology  -  Defoam  Standordimd  Profiles  -  Infont  Tramport  Profile  lor  DoD 
Comomnicntiont,  Part  I:  Transport  and  Internet  Services,  Draft,  1993  (in  SXM  coordination) 
MEL-STD- 1 745-14502-02  Information  Technology  •  Defoam  Standardised  NofBrr  •  Internet  TTamport  ProfBe  for  DoD 
Communications.  Part  2:  Poiat-to-Poiat  Links,  Draft,  1993  (in  SD-1  oorndtoattao) 


5  Them  standards  an  being  developed  by  the  US  DCPS  Technical  llmagmimt  Paoal  (DTMP).  This  Hat  was  npdntad 
baaed  on  a  privala  communication  from  HEOTBBD  (Mr.  Waft  Laocbaai)  on  10  January  1994,  DCPS  WLSTAN-3043 
Metier  Assignments.  whom  effective  date  wm  13  December  1993. 

SD-1  coordination)  for  formal  validation  prior  to  find  approval  and^pnbUccation.  (fowrporaaing 
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UNCLASSIFIED 


UNCLASSIFIED 


kflIL-STD- 1 745-14502-03  Information  Technology  -  Defense  Standardized  Profile*  -  Internet  Tnuput  Profile  for  DoD 
Co— Micrttone  Part  3:  Wide  Area  Network  Access.  Draft,  1993  (in  SD-1  coordination) 
MIL-STD-1745-14502-04  Information  Technology  -  Defense  Standardized  Profiles  •  Internet  Transport  Profile  for  DoD 
ComsmicatioBt,  Part  4:  Local  Area  Network  (LAN)  Media  Independent  Requirements,  Draft,  1993 
(in  SD-1  coordination) 

MIL-STD-1745-14502-05  Information  Technology  -  Defense  Standardized  Profiles  •  Internet  Transport  Profile  for  DoD 
Comannications,  Part  5:  Carrier-Sense  Multiple  Access  with  Collision  Detection  (CSMA/CD) 
Local  Area  Network  (LAN)  Media  Dependent  Requirements,  Draft,  1993  (in  SD-1  coordination) 
MIL-STTM 745-14502-06  Information  Technology  -  Defense  Standardized  Profiles  -  Internet  Transport  Profile  for  DoD 
Communications,  Part  6:  Combat  Net  Radio,  Draft,  1993  (in  SD-1  coordination) 

MIL-STD- 1 745-44500  Tactical  Communications  2  (TAC02),  Draft,  1993  (sent  to  Navy  publications) 

SMft-Serles— Session  Layer 


MM-Ssrlaa — Presentation  Lsyer 


7ft— -Series— Application  Layer 


75M-Serles— Application  Proflles/Mnlti-Layer7 

MIL-STD-1 745-17501 -01  Information  Technology  -  Defense  Standardized  Profiles  AMH  In  (D  )-  Message  Handling 
System  (MHS)  Common  Messaging,  Part  1:  MHS  Service  Support,  Draft,  1993  (sent  to  Navy 
publications) 

MIL-STD-1745-17501-02  Information  Technology  -  Defense  Standardized  Profiles  AMH  In  (D  )-  Message  Handling 
System  (MHS)  Common  Messaging,  Part  2:  Specification  of  ROSE,  RTSE,  ACSE,  Presentation  and 
Session  Protocols  for  use  by  DoD  MHS,  Draft,  1993  (seat  to  Navy  publications) 

MIL-STD-1745-17501-03  Information  Technology  -  Defense  Standardized  Profiles  AMH  In  (D  y  Message  Handling 
System  (MHS)  Common  Messaging,  Part  3:  Requirements  for  Message  Transfer  (PI),  Draft,  1993 
(■ant  to  Navy  publications) 

MIL-STD-1 745-17501-04  Information  Technology  -  Defense  Standardized  Profiles  AMH  In  (D  )-  Message  Handling 
System  (MHS)  Common  Messaging.  Part  4:  Messaging  Requirements  for  MTS  Access  (P3),  Draft, 
1993  (sent  to  Navy  publications) 

MIL-STD-1 745-17501 -05  Information  Technology  -  Defease  .Standardized  Profiles  AMH  In  (D  )-  Message  Handling 
System  (MHS)  Common  Messaging,  Part  5:  Messaging  Requirements  for  MS  Access  (P7),  Draft, 
1993  (sent  to  Navy  publications) 

MDL-STD-1745- 17502  MHS  MiliUry  Messaging.  Content  Type  AMH  2n  (D).  Draft.  1993  (baseline  for  validation; 
requesting  approval  to  publish  from  DTMP) 

MIL-STD- 1745-17503 -01  Information  Technology  •  Defense  Standardized  Profiles  -  Internet  Message  Transfer  Profile  for 
DoD  Communications,  Part  1:  Simple  Mail  Transfer  Protocol  (in  SD-1  coordination) 

MIL-STD-1 745-17503-02  Information  Technology  -  Defense  Standardized  Profiles  -  Internet  Message  Transfer  Profile  for 
DoD  Communications,  Part  2:  Format  of  Text  Messages.  Draft,  1993  (in  SD-1  coordination) 

MIL-STD- 1745- 17504  Information  Technology  -  Defense  Standardized  Profiles  •  Internet  File  Transfer  Profile  for 
DoD  Communications,  Draft,  1993  (in  SD-1  coordination) 

MIL-STD-1745- 17505  Information  Technology  -  Defense  Standardized  Profiles  -  Internet  Domain  Name  Service 
(DNS)  Profile  for  DoD  Communications,  Draft,  1993  (in  SD-1  coordination) 

MHcSTD-1745-17506  Information  Technology  -  Defense  Standardized  Profiles  -  Internet  Remote  Login  Profile  for 
DoD  Communications,  Draft,  1993  (in  SD-1  coordination) 

MIL- STD-1745-17507 -01  Information  Technology  -  Defease  Standardized  Profiles  -  Internet  Network  Management 
Profile  for  DoD  Communications,  Part  1:  Simple  Network  Management  Protocol  (SNMP),  Draft. 
1993  (in  SD-1  coordination) 

MIL-STD-1745-17507-02  Informatioa  Technology  -  Defense  Standardized  Profiles  -  Internet  Network  Management 
Profile  for  DoD  Communications,  Part  2:  Management  Informatioa  Base  (MIB),  Draft,  1993  (in 
SD-1  coordination) 

MIL- STD-1745-17507 -03  Information  Technology  -  Defense  Standardized  Profiles  •  Internet  Network  Management 
hofile  for  Did)  Part  3:  Structure  and  Identification  of  Management  Informatioa, 

Draft,  1993  (in  SD-1  coordination) 

MIL-STD-1745-17504-01  Information  Technology  -  Defense  Standardized  Profiles  AFT  In  (D)  -  File  Transfer,  Access  and 
Managancot,  Part  1:  Specification  of  ACSE,  Prereotation  and  Session  Protocols  for  Use  by  FT AM, 
Draft,  1993  (hi  SD-1  coordination) 

MIL-STD-1745- 17508 -02  Information  Technology  -  Defense  Standardized  Profiles  AFT  In  (D)  -  File  Transfer,  Access  and 
Management,  Part  2:  Definition  of  Document  Types,  Constraint  Sett  and  Syntaxes,  Draft,  1993  (in 
SD-1  coordtatfkm) 


7  The  US  Joint  Interoperability  Test  Center  (JITC)  has  completed  validation  testing  of  MIL-STD-2045-17501  and 
•17502.  Some  minor  deficiencies  were  noted,  and  foe  DTMP  has  approval  these  for  publication  with  these  corrections. 
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MIL-STD- 1745- 17508 -03  Information  Technology  •  Defence  Standardized  Profiles  APT  In  (D)  -  File  Transfer,  Access  and 
Management,  Part  3:  AFT  11 — Simple  Hie  Transfer  Service  (Unstructured),  Draft,  1993  (in  SD-1 
coordination) 

MIL-STD-1745-17506-04  Information  Technology  -  Defense  Standardized  Profiles  AFT  In  (D)  -  File  Transfer,  Access  and 
Management,  Part  4:  AFT  12 — Positional  Hie  Transfer  Service  for  Hat  Hies,  Draft,  1993  (in  SD-1 
coordination) 

MIL-STD-1745-17506-05  Information  Technology  -  Defense  Standardized  Profiles  AFT  In  (D)  •  File  Transfer,  Access  and 
Management,  Part  5:  AFT  22 — Positional  File  Access  Service  for  Flat  Hies,  Draft,  1993  (in  SD-1 
coordination) 

MIL-STD-1 745-17508-06  Information  Technology  •  Defense  Standardized  Profiles  AFT  In  (D)  -  File  Transfer,  Access  and 
Management,  Part  6:  AFT  3— File  Management  Service,  Draft,  1993  (in  SD-1  coordination) 

——-Series— -Network  Management 

MIL-STD-1 745-38000  Government  Network  Management  Profile  (GNMP),  1991  (approved  and  published) 

MIL-STD-1 745-38000  DoD  Network  Management  for  DoD  Communications.  Version  2  of  GNMP,  Draft  (working 

group  circulation),  DTMP/WG3,  1992 

SS— -Series— Secnrity^ 

MIL-STD-1745- 18500 -01  Information  Technology  -  Defense  Standardized  Profiles  AMH  Xn  (D)-  Message  Handling 
System  (MHS)  Message  Security  Protocol,  Part  1:  MSP  Service  Support,  Draft,  DTMP/WG3, 1993 
(seat  to  Navy  publications) 

MIL-STD-1745-18500-02  Information  Technology  -  Defense  Standardized  Profiles  AMH  Xn  (D)-  Message  Handling 
System  (MHS)  Message  Security  Protocol,  Part  2:  MSP  Content  Protocol,  Draft,  DTMP/WG3. 1993 
(seat  to  Navy  publications) 

MIL-STD- 1 745-18500-03  Information  Technology  -  Defense  Standardized  Profiles  AMH  Xn  (D>-  Message  Handling 
System  (MHS)  Message  Security  Protocol,  Part  3:  MSP  Requirements  for  Message  Transfer,  Draft, 
DTMP/WG3,  1993  (sent  to  Navy  publications) 

MIL- STD-1745-18500-04  Information  Technology  -  Defense  Standardized  Profiles  AMH  Xn  (D>-  Message  Handling 
System  (MHS)  Message  Security  Protocol,  Part  4:  MSP  Requirements  for  MS  Access,  Draft, 
DTMP/WG3,  1993  (sent  to  Navy  publications) 

MIL-STD-174S-18500-05  Information  Technology  -  Defense  Standardized  Profiles  AMH  Xn  (D)-  Message  Handling 
System  (MHS)  Message  Security  Protocol,  Part  5:  MSP  Requirements  for  MS  Access,  Draft, 
DTMP/WG3,  1993  (sent  to  Navy  publications) 

MIL-STD-1745-48501  Common  Security  Label.  Draft,  1993  (in  SD-1  coordination) 

MIL-HDVK -Series 

MIL-HDBK-829-1  (Vol  1)  MIL-5TD-2045-Series  Documentation.  Volume  1,  DTMP/WG5,  23  April  1993  (published) 

MIL-HDBK-829-2  (Vol  2)  Guidelines  for  Data  Communications  Protocol  Standards  (DCPS)  DoD  Standardized  Profiles 
(DSPs),  Volume  2.  DTMP/WG5, 23  April  1993  (published) 

MIL-HDBK-1350-1  (Vol  1)  Validation  of  Data  Communications  Protocol  Standards  for  Military  Applications, 
DTMP/WG7,  Draft,  1993  (requesting  DTMP  approval  for  SD-1  ooardinatioo) 

MIL-HDBK- 1350-2  (Vol  2)  Data  Communications  Protocol  Conformance  and  Interoperability  Testing  and  Registration, 
DTMP/WG7,  Draft,  1993  (requesting  DTMP  approval  for  SD-1  coordination) 

MIL-HDBK-13S1  Network  Management  for  DoD  Communications,  DTMP/WG4,  23  July  1993  (sent  to  Navy 
publications) 


C.  US  DoD  STANDARDS— OTHER  MIL-STDs 

MIL-STD- 188-1 14A  Electrical  Characteristics  of  Digital  Interface  Circuits,  July  1984 

MIL-STD- 188C  Military  Communication  System  Technical  Standards,  November  1969 

MIL-STD-188-100  Common  Long-Haul  and  Tactical  Communication  System  Technical  Standards,  November  1972 

MIL-STD-188-148(S)  Interoperability  Standards  for  Anti-Jam  Communications  in  the  HF  Bad  (U) 

MEL-STD-188-196  Bi-Level  Image  Compression  for  the  National  Imagery  Transmission  Format  Standard, 


MIL-STD-188-197 
MIL-STD-1S8-220 
MIL-STD- 198 


18  June  1993 

Adaptive  Recursive  Interpolated  Differential  Pulse  Code  Modulation  (ARIDPCM)  Compression 
Algorithm  for  the  National  Imagery  Transmission  Format  Standard,  18  June  1993 
Interoperability  Standard  for  Digital  Message  Transfer  Device  (DMTD)  Systems,  1993  (approved 
and  published) 

Joint  Photographic  Experts  Group  (JPEG)  Image  Compression  for  National  Imagery  Transmission 
Format  Standard,  18  June  1993 


MIL-STD-974 
MIL-STD- 1379D 
MIL-STD-1 388 -2B 
MIL-STD- 1472D 
MIL-STD- 1777 


Contractor  Integrated  Technical  Information  Service  (CTTIS),  Fall  1993 
Military  Training  Programs 

DoD  Requirements  for  a  Logistic  Support  Analysis  Record 

Human  Engineering  Design  Criteria  for  Military  Systems,  Equipment  and  Facilities.  March  1989 
Internet  Protocol  (IP),  August  1983 


1  MIL-STD- 2045- 1 8500  hm  been  validated  by  the  US  JITC. 
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M&-tfD»1778 

kHL-STD-1779 

MIL-STD-17tO 

MIL-STD-1781 

MIL-STD- 1782 

MIL-STD- 1800A 

MIL-STD-1801 

MD<SYD-!S15A 

MIL-&ID-1840B 

MIL-STD- 2045-44500 

M1L-STD-2167A 
MIL-STD-2168 
MIL-STD- 2301 


taaWot  Control  Protocol  (TCP),  August  190 

bMm  for  High  Capacity  C3  Local  Area  Networks,  November  190 

ilia  Ikanafer  Protocol  (FTP),  May  1984 

Simple  Mail  Traoafar  Protocol  (SMTP),  May  1984 

TELENET  Protocol.  May  19S4 

Hotoao  Bogtoaariag  Parformanca  Requirements  for  Systems,  October  1990 

UeecsComputar  Interface,  May  1987 

Ada  Programming  Language  (ISO  8652),  190 

Antrim  alert  Interchange  of  Technical  Information,  3  November  1992 

Tactical  Communications  Protocol  2  (TAC02)  for  National  Imagery  Transmission  Format 
Standard,  18  June  1993 

Dafanae  System  Software  Development  Standard 
Defense  System  Software  Quality  Program 

Compotar  Oraphics  Metafile  (COM)  Implementation  Standard  for  the  National  Imagery 
Tlrammttfion  Fonnat  Standard,  18  June  1993 


MIL-STD-2500 

MIL-STD-7035A 

MIL-STD-SDS 

MIL-T-31000 


National  Imagery  Transmission  Fonnat  (Version  2.0)  for  the  National  Imagery  Trmsraissioo 

Format  Slanted,  18  June  1993 

Defense  System  Software  Documentation  Standard 

Defanae  System  Software  Development  and  Documentation  Standard 

Oeneral  Specifications  for  Technical  Data  Packages  (supersedes  Do  D-D- 1000,  Engineering 
Drawings  nid  Associated  Lists) 


D.  US  DoO  STANDARDS— DoD  INTERNET  REQUESTS  FOR  COMMENT  (RFCs) 

RFC®  742  Rngar  Protocol  (Elective,  Proposed  Standard) 

RFC  768  Uaar  Datagram  Protocol  (UDP)  (Recommended) 

RFC  783  Trivial  File  Transfer  Protocol  (TFTP)  (Elective.  Draft  Standard) 


RFC  791 
RFC  792 
RFC  793 
RFC  821 
RFC  822 
RFC  826 
RFC  834 
RFC  862 
RFC  863 
RFC  864 
RFC  865 
RFC  866 
RFC  867 
RFC  868 
RFC  877 
RFC  891 
RFC  894 
RFC  895 
RFC  909 
RFC  904 
RFC  907 
RFC  919 
RFC  922 
RFC  930 
RFC  931 
RFC  934 
RFC  939 
RFC  1001-1002 
RFC  1006 
RFC  1009 
RFC  1094-1095 
RFC  1042 
RFC  1044 


Internet  Protocol  (IP)  (Required) 

Internet  Control  Message  Protocol  (ICMP)  (Required) 

Transmission  Control  Protocol  (TCP)  (Recommended) 

Simple  Mail  Transfer  Protocol  (SMTP)  (Recommended) 

Format  of  Electronic  Mail  Messages  (MAIL)  (Recommended) 

Address  Resolution  Protocol  (ARP)  (Elective) 

TELNET  Protocol  (Recommended) 

Echo  Protocol  (ECHO)  (Recommended) 

Discard  Protocol  (DISCARD)  (Elective) 

Chamctor  Generator  Protocol  (CHARGEN)  (Elective) 

Quota  of  the  Day  Protocol  (QUOTE)  (Elective) 

Active  llama  Protocol  (USERS)  (Elective) 

Daytime  Protocol  (DAYTIME)  (Elective) 

Time  Server  Protocol  (TIME)  (Elective) 

internet  Protocol  on  X.25  Networks  (IP-X25)  (Elective) 

Interact  Protocol  on  DC  Networks  (IP-DC)  (Elective) 

Iutoraat  Protocol  on  Ethernet  Networka  flOP-E)  (Elective) 

Internet  Protocol  on  Experimental  Ethernet  Networks  (IP-EE)  (Elective) 
A  Reverse  Address  Resolution  Protocol  (RARP)  (Elective) 

Exterior  Gateway  Protocol  (EGP)  (Recommended) 
latomet  Protocol  on  Wideband  Networka  (IP-WB)  (Elective) 

Intamat  Protocol  Broadcast  Datagrams  (Required) 

tamraet  Protocol  Broadcast  Datagrams  With  Subnets  (Required) 

Intwnat  Protocol  Soboet  Extension  (Required) 

Bootstrap  Protocol  (BOOTP) 

Who  la  Protocol  NICNAME)  (Elective,  Draft  Standard) 

Pile  Transfsr  Protocol  (FTP)  (Recommended) 

NetBIOS  Service  Protocol  (Elective) 

ISO  Transport  Service  on  Top  of  TCP  (TP-TCP)  (Elective,  Draft  Standard) 
Gateway  Requirements  (Required) 

Domain  Name  System  (Recommended) 

InMrnet  Protocol  on  IEEE  802  (IP-IEEE)  (Elective) 

Inmost  Protocol  on  Hypercbannel  Networks  (IP-HC)  (Elective) 


®  The  Hat  of  Internet  RaqoeeU  for  Comment  (RFCs)  was  updated  from  the  Internet  Information  Services,  RFC  Directary, 
available  on  DMSOPROTO,  September  1993 
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Bootstrap  Protocol  (BOOTP)  (Recommended,  Draft  Standard) 

Content  of  Header  Type  (CONTENT)  (Recommended) 

Internet  Protocol  on  ARCNET  (IP-ARC)  (Elective) 

Internet  Group  Multicast  Protocol  (IGMP) 

Tranamisiioc  of  IP  Over  Serial  Lines  (IP-SUP)  (Elective) 

Rooting  Information  Protocol  (RIP)  (Elective,  Draft  Standard) 

Network  Time  Protocol 
Assigned  Numbers  (Required) 

Bootstrap  Protocol  (BOOTP)  (Recommended,  Draft  Standard) 

Transmissive  of  IP  Over  NetBIOS  (IP-NETBIOS)  (Elective) 

Common  Management  Information  Services  and  Protocol  Over  TCP/IP  (CMOT)  (Recommended, 
Draft  Standard) 

Transmission  of  IP  Over  FDD!  (IP-FDDI)  (Elective) 

Internet  Group  Multicast  Protocol  (IGMP)  (Recommended) 

Mail  Privacy  (Procedures.  Key  Management,  and  Algorithms)  (Elective,  Draft  Standard) 

Host  Requiraments-Commimications  (Required) 

Hoet  Requirements— Applications  (Required) 

Transmission  of  802.2  over  IPX  Nets  (IP-IPX  (Elective) 

Structure  of  Manegement  Information  (SMI)  (Recommended) 

Manegement  Information  Base  (MDB)  (Recommended) 

Simple  Network  Management  Protocol  (SNMP)  (Recommended) 

Network  Time  Protocol  (NTP)  over  the  OSI  Remote  Oparatione  Service 

Point-to- Point  Protocol  for  the  Transmission  of  Multi-Protocol  Datagrams  over  Point-to-Poiat 
Links,  D.  Perkins,  July  1990 

The  Point-to-Point  Protocol  (PPP)  Initial  Configuration  Options,  D.  Parkins  end  R.  Hobby.  1990 
IAB  recommended  policy  on  distributing  internet  identifier  assignment  and  IAB  recommended 
policy  chenge  to  internet  ’connected*  status 
Interactive  Mail  Access  Protocol:  Version  2 
Line  printer  daemon  protocol. 

Proposed  standard  for  the  transmission  of  IP  datagrams  over  FDDI  networks 

Handspicker,  B.  Common  Management  Information  Services  and  Protocols  for  the  Internet  (CMOT 

andCMIP) 

Experimental  Internet  Stream  Protocol:  Version  2  (ST-II) 

Path  MTU  discovery 

Internet  Protocol  on  ARPANET  IIP-ARPA)  (Elective) 

Interactive  Mail  Access  Protocol:  Version  3 
Message  Posting  Protocol  (MPP) 

Point-to-Point  Protocol  Extensions  for  Bridging 

Host  Access  Protocol  (HAP)  specification:  Version  2 

OSI  CLNS  and  LLC1  protocols  on  Network  Systems  HYPERcbsrmel. 

Post  Office  Protocol:  Version  3 
SNMP  MUX  protocol  and  MIB 

SNMP-DPI:  Simple  Network  Management  Protocol  Distributed  Program  Interface 
Coherent  File  Distribution  Protocol 

Guidelines  for  OSI  NSAP  Allocation  in  the  Internet,  R.  Colella,  E.  P.  Gardner,  and  R.  W.  CaDon. 
Inly  1991 

OSI  connectionless  transport  services  on  top  of  UDP:  Version  1 

Scheme  for  an  internet  encapsulation  protocol:  Version  1 

Site  Security  Handbook 

OSPF  version  2 

DIXIE  protocol  specification 

OSPF  version  2:  Management  Information  Base 

A  Border  Gateway  Protocol  3  (BGP-3) 

Guidelines  for  the  Secure  Operation  of  the  Internet 
The  Finger  User  Information  Protocol 
Inverse  Address  Resolution  Protocol 
Multicast  Transport  Protocol 

Network  Time  Protocol  (Version  3)  Specification,  Implementation  sad  Analysis 
Dynamically  Switched  Link  Control  Protocol 

The  Point-to-Point  Protocol  (PPP)  for  the  Transmission  of  Multi-protocol  Datagrams  over  Point-to- 
Point  Links 

The  PPP  Internet  Protocol  Control  Protocol  (IPCP) 

PPP  Authentication  Protocols 
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RMMtti  Mill  Protocol 

THE  TFH»  PROTOCOL  (REVISION  2\  (Obeoletm  RPC  783) 

SNMP  Secority  Protocols 

Simple  Network  Time  Protocol  (SNTP) 

TVs  PPP  DECnet  Pba*  IV  Control  Protocol  (DNCP) 

The  PPP  OSI  Netwcxfc  Layer  Cootrol  Protocol  (OSINLCP),  November  1992 
The  PPP  AppleTalk  Control  Protocol  (ATCP) 

EIP:  The  Extended  Internet  Protocol  A  Framework  for  Maintaining  Backward  Compatibility 

RIP  Vanion  2  -  Carrying  Additional  Information 

Telnet  Authentication;  Kerberoe  Vcrtioo  4 

Identification  Protocol 

FTP-FTAM  Gateway  Specification 

SNMP  over  OSI 

SNMP  over  AppleTalk 

Privacy  Enhancement  for  Internet  Electronic  Mail:  Part  I;  Meaaage  Encryption  and  Authentication 
Procedures,  (Obsoletes  RFC  1113) 

Privacy  Enhancement  for  Internet  Electronic  Mail;  Part  II:  Certificate-Baaed  Key  Management 

Privacy  Enhancement  for  Internet  Electronic  Mail:  Part  E:  Algorithms,  Modes,  and  Identifiers 

Privacy  Enhancement  for  Internet  Electronic  Mail:  Pvt  IV:  Key  Certification  and  Related  Services 

SMTP  Service  Extensions 

SMTP  Service  Extension  for  8-bit-MIME  transport 

Listserv  Distribute  Protocol 

Data  Link  Switching:  Swilcb-to-S witch  Protocol 

The  Internet  Gopher  Protocol 
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III.  AGREEMENTS  FROM  REGIONAL  WORKSHOPS 


ED  024 

EWOS/ETG003 
EWOS/EG  VT/89 


Profile  RC  p,q 
ECMATR/46 

ECMATR/55 

fc.  MA  149 

ECMAIS8 

ECMA  162 
ENV1041  101 

ENV41  102 

ENV41  103 

ENV41  104 
ENV41  105 
ENV41  106 

ENV41  107 
ENV41  108 
ENV41  109 
ENV41  110 

ENV41  111 
ENV41  112 
ENV41  201 

ENV  41  202 

ENV41  203 

ENV  41  204 
ENV  41  205 
ENV  41  206 
ENV  41  207 
ENV  41  208-1 

ENV  41  208-2 

ENV  41  208-3 

ENV  41  209 

prENV  41  210 
peENV  41  211-1 

prENV  41  211-2 


Application  Function  A/713,  Behavior  of  DSAs  for  Distributed  Operations,  European  Workshop  for 
Open  Systems,  [EWOS  EGDIR/91/29],  Final  Draft,  February  1991 

EWOS/EG  FT,  File  Transfer  Access  and  Management  -  FT  AM  Remote  Actions  (RA)  Service  and 
Protocol,  24  January  1990 

Application  Function  A/4121,  Basic  Class  VT  S-Mode  Forms  Functional  Standard,  Part  1:  Virtual 

Terminal  Service,  EWOS/EG  VT/89/53.  Part  2:  VT  Protocol  Check  List,  EWOS/EG  VT/89/59,  and 

Part  3:  Underlying  Layers  Check  List,  EWOS/EG  VT/89/60,  Final  Text,  prENV  41  208 

X.25  Protocol  Relaying,  Draft,  EWOS/EGLL/2990/81,  EWOS.  9  May  1990 

Security  in  Open  Systems-A  Security  Framework,  ECMA  TR/46,  European  Computer  Manufacturers 

Association,  July  1988 

Reference  Model  for  Frameworks  on  Computer  Assisted  Software  Engineering  Environments, 
developed  by  ECMA  TC33  Technical  Group  on  Reference  Models  (TGRM),  December  1990. 

Portable  Common  Tools  Environment  (PCTE)  Abstract  Specification,  European  Computer 
Manufacturers  Association,  December  1990 

Portable  Common  Tools  Environment  (PCTE)  C  Programming  Language  Binding,  European 
Computer  Manufacturers  Association,  June  1991 
PCTE  Ada  Program  Language  Binding,  December  1991 

LANs:  Provision  of  the  OSI  Connection-Mode  Transport  Service  (COTS)  Service  .ing  the 
Connectionless-Mode  Network  Service  (CLNS)  on  a  CSMA/CD  Single  LAN,  June  1986 
LANs:  Provision  of  the  OSI  COTS  and  the  CLNS  on  a  CSMA/CD  Single  or  Multiple  LAN 
Configuration,  June  1986 

LANs:  Provision  of  the  OSI  COTS  and  the  Connection-Mode  Network  Service  (CONS)  in  an  End 

System  on  a  CSMA/CD  LAN,  August  1990 

Packet  Switched  Data  Networks:  Permanent  Access,  August  1987 

Packet  Switched  Data  Networks:  Switched  Access,  June  1988 

Digital  Data  Circuit  (CSDN)  -  Provision  of  the  OSI  COTS  in  the  T.70  Case  for  Telematic  End 
Systems,  June  1988 

Digital  Data  Circuit  (CSDN)  -  Provision  of  the  OSI  COTS  and  the  OSI  CONS,  June  1988 
LANs:  Provision  of  the  OSI  COTS  and  CONS  in  an  End  System  on  a  Token  Ring  LAN,  August  1990 
LANs:  Provision  of  the  OSI  COTS  Using  CLNS  on  a  Token  Ring  Single  LAN,  February  1988 
LANs:  Provision  of  the  OSI  COTS  Using  CLNS  in  an  End  System  on  a  Token  Ring  LAN  in  a  Single 
or  Multiple  LAN  Configuration,  February  1988 
ISDN:  X.25  DTE  to  DTE  Operation  (B-cbannel) 

ISDN:  X.25  DTE  to  DTE  Operation  (Circuit-mode  service) 

Private  Message  Handling  System  -  User  Agent  and  Message  Transfer  Agent;  Private  Management 
Domain  to  Private  Management  Domain,  June  1986 

Message  Handling  Systems;  User  Agent  and  Message  Transfer  Agent:  Access  to  an  Administration 
Management  Domain  (ADMD),  August  1987 

Exchange  of  Telex  Documents  Between  Two  End  Systems,  Which  May  Be  Teletex  Terminals, 
June  1988 

FT  AM:  Simple  File  Transfer,  September  1989 
FT AM:  File  Management,  June  1989 
FT AM:  Positional  File  Transfer,  September  1989 
FTAM:  Positional  File  Access  Service,  September  1989 

Information  System  Interconnection  -  Buie  Class  Virtual  Terminal  -  S-mode  Forms  -  Part  1:  Virtual 
Terminal  Service,  European  Prestandard,  December  1990 

Information  System  Interconnection  -  Basic  Class  Virtual  Terminal  -  S-mode  Forms  -  Part  2:  Check 
List,  European  Prestandard,  December  1990 

Information  System  Interconnection  •  Basic  Class  Virtual  Terminal  -  S-mode  Forms  ''art  3: 
Underlying  Layers  Checklist,  European  Prestandard,  December  1990 

Information  System  Interconnection  -  Basic  Class  Virtual  Terminal  •  Common  Control  Objects, 
European  Prestandard,  December  1990 
Directory:  Directory  Access  Protocol,  April  1990 

Information  Systems  Interconnection  -  Virtual  Terminal  Basic  Class  -  A-mode  X.3  (A/VT15)  - 
Part  1:  Virtual  Terminal  Service,  May  1991 

Information  Systems  Interconnection  -  Virtual  Terminal  Basic  Class  -  A-mode  X.3  (A/VT15)  - 
Part  2:  Virtual  Terminal  Protocol  Checklist,  May  1991 


10  ENV  indicates  a  standard  approved  by  the  Join  European  Standards  Institution  (CEN/CENELEC)  and  the  European 
Workshop  for  Open  Systems  (EWOS). 
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Information  Systems  Interconnection  -  Virtual  Terminal  Buie  Clut  -  A -mod*  XJ  (A/VT13)  • 
Part  3:  Underlying  Layers  Checklist,  May  1991 

Information  Syctama  Interconnection  -  Directory  Syatem  Protocol  (A/DI2),  May  1991 
Information  Syatema  Interconnection  •  Vbtnal  Terminal  Buie  Oats  •  A-mode  Telnet1  (A/VT13)  - 
Part  1:  Virtual  Terminal  Service,  May  1991 

Information  Syatema  Interconnection  -  Virtual  Terminal  Buie  Clau  •  A-mode  Telnet*  (A/VT13)  - 
Part  2:  Virtual  Terminal  Protocol  Checklist,  May  1991 

Information  Syatema  Interconnection  -  Virtual  Terminal  Buie  Clau  -  A-mode  Telnet  (A/VT13)  - 

Part  3:  Underlying  La  yen  Checkliat,  May  1991 

Data  Stream  Formate,  Character-coded  Text,  Telex-compatible 

Data  Stream  Formate,  Character-coded  Text,  Tsletex -compatible 

Data  Stream  Formate,  Character-coded  Text,  Videotex -compatible 

ODF.  Simple  Document  Structure,  Character  Content  Architecture  Only,  January  1989 

ODF:  Balanced  Document  Structure,  Character,  Harter,  Geometric  Graphic*  Content  Architecture, 

January  1989 

ODF:  Proceaaable  and  Layout  Independent  Documents,  Simple  Messaging  Profile,  January  1989 
Directory  Data  Definition*.  Common  Directory  Use,  April  1990 

Information  Syatema  Interconnection  -  Virtual  Terminal  Baric  Clau  •  VT  Font  Assignment  Type  1 
(F/441),  July  1991 

X.  29-Mode  Procedures  Between  a  Packet  Mode  DTE  or  a  PAD  and  a  PAD  via  a  Public  or  Private  XJ5 
Packet  Switched  Network  or  ISO  8208  Packet  Level  Entity  and  ISO  7776  1  inV  Level  Entity,  June 
1987 

Integrated  Service*  Digital  Network  (ISDN):  File  Transfer  over  the  ISDN  (Using  the)  EUROFILE 
Transfer  Profile,  ETSI,  December  1993 

Integrated  Services  Digital  Network  (ISDN):  File  Transfer  end  Acceu  Management  (FT AM)  over 
ISDN  Baaed  on  Simple  File  Transfer  Profile,  ETSL  December  1993 

The  Induatry/Qovemmeut  Open  Syatema  Specification  (IGOSS),  Draft.  IOOSS  Panel.  January  1994 
(expected  to  be  published  u  Version  1  in  1994;  IGOSS  is  a  joint  effort  by  tbe  US  Government,  the 
Canadian  Government,  MAP  Users  Group,  TOP  Users  Group,  and  tbe  Electric  Power  Research 
Institute) 

Manufacturing  Automation  Protocol  (MAP),  World  Federation  of  MAP/TOP  Users  Groups 
(distributed  by  tbe  Corporation  for  Open  Systems) 

The  Concept  of  Profiles  and  Structure  for  Functional  Standards  for  Information  Technology, 
Adopted  by  CEWCENELEC/ETSI  nSTC.  1991 

Taxonomy  of  Profiles  aid  Directory  of  Functional  Standards  (For  Interworking  in  an  OSI 
Environment)  Adopted  by  CEN/CENELEC7ETSHTSTC,  1991 
A  Framework  for  Testing  and  Certification  in  Europe  (being  implemented  by  ECITC) 

Stable  Implementation  Agreements  (SIA)  for  Open  Systems  Interconnection  Protocols,  Version  6, 
Proceedings  of  the  December  1992  NIST  OSE  Implementor's  Workshop  (OIW),  March  1993 
Stable  Implementation  Agreements  (SIA)  for  Open  Systems  Interconnection  Protocols,  Version  7, 
Proceedings  of  the  December  1993  NIST  OSE  Implementor's  Workshop  (OIW),  January  1994 
(electronic  edition  is  available;  publication  is  forthcoming) 

Working  Implementation  Agreements  (WlA),  Proceedings  of  the  December  1991  NIST  OSE 
Implementor's  Workshop  (OIW),  March  1992 

Working  Implementation  Agreements  (WIA),  Proceedings  of  the  December  1991  NIST  OSE 
Implementor's  Workshop  (OIW),  March  1994  (electronic  edition  is  available;  publication  is 
forthcoming) 

Technical  Office  Protocol  (TOP),  World  Federation  of  MAP/TOP  Users  Group*  (distributed  by  the 
Corporation  for  Open  Systems) 

X-Wlndow  System,  X  Version  11,  Release  4  (X11-R4),  MJ.T.  X  Consortium 
ZJ9J0  Implementors  Group  Profile,  ANSI  239 J0-MA-026 

Gatdee 

FTAM  -  Tutorial  on  Rules  for  ASN.l  Encoding,  April  1989 

FTAM  •  Remote  Actions  (RA)  over  FTAM,  Service  and  protocol.  Edition  2,  May  1992 

Introduction  to  Directory  Profiles,  Edition  3,  May  1993 

FTAM  •  Service  Classes  and  Functional  Units  in  ENV  41  205,  Edition  2,  August  1990 

Procedures  and  Evaluation  Criteria  for  Standardization  of  Teat  Specifications  for  European 

Functional  Standards,  October  1990 

Conformance  Vocabulary,  Edition  2,  September  1992 

Conformance  Tutorial,  January  1991 

Tutorial  for  Directory  Q-Profile  Production,  January  1991 

A  Mapping  of  the  X- Window  System  over  an  OSI  Stack,  May  1991 

PTS  Specification,  February  1992 

Error  Handling  in  Directory,  May  1992 

OSI  TP  Tutorial,  Part  l,  September  1992  and  Part  2,  May  1993  (separate  volumes) 
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BW08BTO020  PTS  Hilnlin.Tr  Pwcedurat.  Saptombw  1992 

EWOSBTO022  Organization  of  Common  PTS,  Novembsr  1992 

EWOSETO025  Tbe  TTCN  Style  Guide  nd  Quality  Criteria,  November  1993 

EWOSETG026  Role  of  Standard*  in  OSI  Testing,  Edition  2,  February  1993 

EWOSETDQ27  Security  Architecture  for  the  Directory,  Februwy  1993 

EWOS  ETC  028  Interoperability  •  Vocabulary,  May  1993 

EWOS  ETO  029  Interoperability  •  Classification.  May  1993 

EWOSETOxxx  Library  of  Teat  Specifications,  Draft  (ETG  expected  November  1993) 

EWOSETOxxx  Technical  Guide  to  ISO  9646  Teat  Environment,  Draft  (ETG  expected  November  1993) 
EWOSETOxxx  Interconnection  of  Directory  Dormice  (DMD-DMD).  Draft  (ETG  expected  November  1993) 
EWOSETOxxx  Methodology  Handbook  far  PTS  Production,  Draft  (replaces  ETC  006;  ETC  expected  February  1994) 

EWOSETOxxx  Te*t  Report  Proforma*,  Draft  (ETC  expected  February  1994) 

EWOSETOxxx  Development  of  Taxooomy  for  DBE  Requirement*,  Draft  (ETC  expected  March  1994) 

EWOSETOxxx  Technical  Framework  for  Security-Related  Profile  Development,  Draft  (ETC  expected  May  1994) 

EWOSETOxxx  Application  of  Security  Technique*  to  Baae  Standard!,  Draft  (ETG  expected  May  1994) 
EWOSETOxxx  Uier  Requirement*  fur  More  DBE  Profiles,  Draft  (ETG  expected  September  1994) 

EWOSETOxxx  Policy  Statement  oo  tbe  Role  of  Standards  in  OSI  Testing,  Draft 

Regional  Workshop  Technical  Reports 

RWS-TR  001  Guiding  Principals  for  Regiooal  Requirements 

RWS-TR  xxx  Guidelines  for  Managed  Object  Profiling  and  Taxonomy  (EWOS),  November  1993  (RWS-TR 

expected  February  1994) 

RWS-TR  xxx  Framework  for  Conformance  Testing  of  Network  Management  Profiles  (EWOS).  September  1993 

(RWS-TR  expected  February  1994) 

RWS-TR  xxx  Registration  of  Object  Identifiers  in  ISPs  (EWOS  SD-16;  EWOS  approval  expected  March  1994) 

RWS-TR  xxx  Conformance  Testing  Vocabulary  (EWOS  approval  expected  May  1994) 

RWS-TR  xxx  TTCN  Style  Guide  (EWOS  approval  expected  November  1994) 

RWS-TR  xxx  Library  of  Test  Specifications  (EWOS  approval  expected  November  1994) 

RWS-TR  xxx  Guidelines  for  Managed  Object  Harmonization  (EWOS  approval  expected  November  1994) 

RWS-TR  xxx  Ensembles  Guidelines  (EWOS  approval  expected  November  1994) 

RWS-TR  xxx  Test  Case  Selection  Rules  (OIW) 

Regional  Workshop  Technical  Paper 

EWOS  TA/92/201  Vocabulary  of  Terms  Used  in  Communication  Protocols  Conformance  Testing.  July  1992 
EWOS  TAW/202  Framework  for  Conformance  and  Testing  of  Network  Management  Profiles,  July  1992 

EWOSTA/93WO  A  Tutorial  on  Upper  Layer  Naming  tod  Addressing.  February  1993 

EWOS  TA/93/114  Upper  Layer  Naming  sod  Addressing  Management  Summary,  April  1993 

EWOS  TA/93/238  Final  Report  of  Joint  ETSI/FT  24V-EWOS/PT  N  017:  Guide  for  the  Implementation  of  the  ISOfiEC 
Conformance  Assessment  Process,  July  1993 
EWOS  TA/93/239  Guidelines  for  Managed  Object  Taxooomy  and  Profiles,  July  1993 
EWOS  TA/93/240  EWOS/EG-NM  Statement  of  Intent  about  the  Use  of  CULR  Part  1  Document,  August  1993 
EWOS  TA/93/255  Information  and  Documentation  -  Open  Systems  Iatsrconnectioa  -  ISPs  ALD  In  •  Library  and 
Documentation  Search  and  Retrieve,  Part  1:  Specification  of  ACSE.  Presentation,  and  Session 
Protocols  for  Use  by  ALD  In,  August  1993 

EWOS  TAW/2S6  Information  and  Documentation  •  Open  Systems  Interconnection  -  ISPs  ALD  2n  •  Library  and 
Documentation  Inter-Library  Loan,  Part  2:  Inter-Library  Loan  Generic  for  ALD  2n,  August  1993 
EWOS  TAW/257  Information  and  Documentation  •  Open  Systems  Interconnection  -  ISPs  ALD  2n  -  Library  and 
Documentation  Inter-Library  Loan,  Part  3:  ALD  21,  Inter-Library  Loan  Using  Connsctioo-Otieoted 
ACSE,  August  1993 

EWOS  TA/93/238  Framework  for  Conformance  and  Testing  of  OSI  Msnagemeat  Profiles,  August  1993 

EWOS  TAW/300  Resolutions  of  EWOOTA22,  September  1993 

EWOS  TA/93/318  Annexes  to  tbe  Draft  Summary  Report  of  EWOS/TA22,  Brussels,  7-8  September  1993. 
September  1993 

EWOS  TA/93/320  Invitation  to  a  Special  Meeting  oo  TCP/IP-OSI  Convergence,  EWOS,  October  1993 
EWOS  TA/93/326  Report  of  the  15th  EGN  Meeting  of  3-7  October  1993,  October  1993 

EWOS  TAW/327  Liaison  to  SIM’S  oo  Submission  of  AOM  2x  Taxooomy,  October  1993 

EWOS  TAW/329  Tbe  TTCN  Style  Guide,  EWOS  Technical  Guide  023,  Revision  1,  October  1993 

EWOS  TAW/331  Proposal  for  EWOS  EG  EDL  Chairperson  EWOS  Ad  Hoc  droop  oo  EDL  October  1993 
EWOS  TAW/332  Proposed  New  Work  Item  for  EG  EDI,  Profiling  Methodologies  for  Composite  EDI  Message 
Structures,  October  1993 

EWOS  TAW/334  Proposed  New  Work  Item  for  EG  EDL  Interactive  EDI  and  TP,  October  1 993 

EWOS  TAW/330  Proposed  New  Work  Item  for  EG  CT,  Interoperability  Methodology  Tracking,  November  1993 
EWOS  TAW/335  Proposed  New  Work  Item  for  EG  NM,  I  SO /Internet  Management  Coexistence  Process, 
November  1993 

EWOS  TAW/337  BWOS/TLG  Draft  Explanatory  Report  of  pDISP  11188-2,  Common  Upper  Layer  Requirements, 
Part  2:  Bade  Connection-Oriented  Requirements  for  ROSB-baeed  Profiles,  October  1993 
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UNCLASSIFIED 


UNCLASSIFIED 


EWOS  TA/93/362 

EWOS  TA/93/3S5 
EWOS  TA/93/391 
BWOS  TA/93/399 

EWOS  TA/93/40S 

EWOS  TA/93/424 

BWOSTA/W/425 


Draft  Report  of  the  13th  EWOS/EG-TP  Mooting.  Brussels.  5-7  October  1993,  EWOS/EO-TP 
Secretariat  October  1993 

EWOS/ILG  Report  to  TA23, 23-24  November  1993,  EWOS/TLG  Chefc,  October  1993 
EWOS/TA  Session  oo  TCMP-OSI  Coovergeoce/Coexisteoce.  EWOS,  October  1993 
Minimal  OSI  Upper  Layers  (mOSI)  Portability  and  Convergence,  Briefing  by  Jim  Quigley, 
November  1993 

Annexes  to  the  Draft  Summary  Report  of  EWOS/TA23,  23-24  November  1993,  EWOS. 
December  1993 

Draft  Minutes  of  the  20th  Joint  Meeting  of  EWOS/EG-WR  and  ETSI  STC  IE.  Held  in  Brumels 
44  October  1993,  EWO&EO-WR  Secretariat,  November  1993 

Seventh  Meeting  of  the  EWOS  Expert  Group  on  Database  Enquiry  5-7  October  1993,  Draft  Report, 
BG-DBE,  December  1993 
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UNCLASSIFIED 


IV.  NATIONAL  STANDARDS  AND  PAPERS 


A.  UK  STANDARDS  AND  PAPERS 


UKGOSIP  VoL  1 


UK  OOSJP  Vol.  2 


UKGOSIP  VoL  3 


Users  Handbook 


UK  Government  OSI  Profile,  Volume  I,  Introduction,  Version  5,  Central  Computer  and 
Telecommunicationt  Agency.  London,  1992 

UK  Government  OSI  Profile,  Volume  n.  Specification,  Venion  S,  Central  Computer  and 
Telecommunications  Agency,  London,  1992 

UK  Government  OSI  Profile,  Volume  HE  Procurement  Handbook,  Venion  S,  Central  Computer  and 
Telecommunications  Agency.  London,  1992 

Users'  Open  Systems  Handbook,  Level-7  Limited,  United  Kingdom,  1989 


B.  CA  STANDARDS  AND  PAPERS 

CSA  X243. 110.2  Canadian  OSI  Registration  Procedures  and  Guidelines,  Part  2  Guidelines  for  Network  Service  Access 

Point  Addresses  far  the  Data  Country  Code  Format 


C.  US  STANDARDS  AND  PAPERS11 

AIAA/ANS1 G -009-1991  Guide  for  Implementing  Software  Development  Files  Conforming  to  DoD-STD-2167A,  1991 


ANSUADM  MSS  3-1 
ANSI/AHM  MS53-2 
ANSI/MIL  1813  A 
ANSUNISO  23930 

ANSI/NISO  Z39.58 
ANSI/NISO  Z39.59 
ANSI/NISO  Z39.63 
ANSI/NISO  Z39.67 
ANSI/SMPTE  RP 12S 
ANSI  Tl  .  101 
ANSI  Tl  .  102 
ANSI  T1.103 
ANSI  Tl. 103a 
ANSI  Tl  .  104 

ANSI  T1.1Q5 
ANSI  Tl  .  106 
ANSI  Tl.  107 
ANSI  T1.107a 
ANSI  Tl.lOTb 

ANSI  Tl. 109 

ANSI  T1.U0 
ANSI  Tl. Ill 

ANSI  Tl. 112 

ANSIT1.113 

ANSI  Tl. 113a 

ANSI  Tl. 114 

ANSI  Tl. 115 

ANSIT1.116 


Hie  Format  for  Storage  and  Exchange  of  Images,  Part  1,  Bi-Level  Image  Hie  Format,  1993 
Hie  Format  for  Storage  and  Exchange  of  Images,  Part  2,  JPEG  Image  Coding,  TBD  in  late  1993 
Reference  Manual  for  the  Ada  Programming  Language,  1983 

Information  Retrieval  Application  Service  Definition  and  Protocol  Specification  for  Open  Systems 
Interconnection  (formerly  ANSI  23950-1988),  1992 

Common  Command  Language  for  On-line  Interactive  Information  Retrieval,  1992 

Electronic  Manuscript  Preparation  and  Markup  Standard,  1988 

Interlibrary  Loan  Data  Elements,  1989 

Computer  Software  Description,  1993 

Digital  Interface  Standard.  Draft 

Telecommunications  -  Synchronization  Interface  Standards  for  Digital  Networks.  1987 
Telecommunications  -  Digital  Hierarchy  •  Electronic  Interfaces,  1987 
Telecommunications  -  Digital  Hierarchy  -  Synchronous  DS3  Format  Specifications,  1987 
Telecommunications  -  Digital  Hierarchy  •  Synchronous  DS3  Format  Specifications,  1990 
Telecommunications  -  Exchange-Interexchange  Carrier  Interfaces  -  Individual  Channel  Signaling 
Protocols,  1991 

Telecommunications  -  Digital  Hierarchy  -  Optical  Interface  Rales  and  Fonnata  Specifications,  1991 
Telecommunications  -  Digital  Hierarchy  -  Optical  Interface  Specifications.  1988 
Telecommunications  -  Digital  Hierarchy  -  Formats  Specifications,  1988 

Telecommunications  -  Digital  Hierarchy  -  Format  Specifications  (DS3  Format  Applications).  1990 
Telecommunications  -  Digital  Hierarchy  •  Format  Specifications  (Synchronous  Digital  Data 
Formats),  1991 


Telecommunications  -  Exchange-In tetexchange  Carrier  Interfaces  -  950+XXXX  EC-to-IC  Access 
Signaling  Protocols,  1990 

Telecommunications  -  Signaling  System  No.  7  (SS7)  -  General  Information,  1992 
Telecommunications  •  Signaling  System  Number  7  -  Functional  Description  of  the  Signaling 
System  Message  Transfer  Part  (JOT),  1992 

Telecommunications  •  Signaling  System  Number  7  •  Signaling  Connection  Control  Past  (SCCP), 


Signaling  Protocols, 
Telecommunications 


User  Part,  1992 


Signaling  System  No.  7  (SS7)  •  Integrated  Services  Digital  Network  (ISDN) 


Triocotmnn  ideations  •  Signaling  System  No.  7  (SS7)  -  Integrated  Services  Digital  Network  (ISDN) 
User  Part  (NxDSO  Multi-Rate  Connection),  1993 

Telecommunications  .  Signaling  System  Number  7  (SS7)  -  Transaction  Capability  Application  Part 
(TCAP),  1992 

Telecommunications  •  Monitoring  sad  Measurements  for  Signaling  System  Number  7  Networks, 
1990 

Telecommunications  -  Signaling  System  Number  7  (SS7)  •  Operations,  Maintenance  and 
Administration  Part  (OMAP),  1990 


Updated  March  1991  from  Accrtdiud  Standard!  Committee  X3  -  Information  Processing  System!  Project!  Mamad, 
X3/SD-4,  CBEMA.  August  1990;  1994  ANSI  Catalog;  and  periodically,  from  ASCX3  New  Relemes. 
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UNCLASSIFIED 


ANSZT1.117 
ANSI  Tl. Ill 

ANSI  T1 .201 

ANSI  Tl  .202 

ANSI  Tl  .203 
ANSI  Tl. 204 

ANSI  Tl  .205 

ANSI  Tl  .206 
ANSI  Tl  .207 

ANSI  Tl. 201 

ANSI  Tl  . 209 
ANSI  T1.210 

ANSI  Tl  .210 

ANSI  Tl  . 211 
ANSI  T1.212 
ANSI  Tl. 213 
ANSI  T1.214 
ANSI  TlJI4a 

ANSI  Tl  .215 

ANSI  T1.216 

ANSI  Tl  .217 

ANSI  T1.218 
ANSI  Tl. 219 
ANSI  Tl  .220 

ANSI  T1.221 

ANSI  Tl. 224 

ANSI  Tl  .226 

ANSI  Tl  027 

ANSI  Tl. 22* 

ANSI  Tl  .229 

ANSI  Tl. 231 

Appendix  H 


Telecom  mnnicatirt  ns  •  Digital  Hierarchy  -  Optical  Interface  Specifications  (Short  Reach),  1991 
Telecommunications  -  Signaling  System  Number  7  (SS7)  -  Intermediate  Signaling  Netwoik 
Identification  (ISNI),  1992 

Telecommunications  •  Information  Interchange  -  Structure  for  the  Identification  of  Location  Entities 
for  the  North  American  Telecommunications  System,  1987 

Telecommnnications  •  Internetwork  Operations  -  Guidelines  for  Network  Management  of  the  Public 
Switched  Networks  Under  Disaster  Conditions,  1988 

Trlocommucicatioor  •  Operations  and  Maintenance  -  Human-Machine  Language,  1988 
Telccommnnif ations  -  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  - 
Lower-Layer  Protocols  for  Interfaces  between  Operations  Systems  and  Network  Elements,  1992 
Telecommunications  -  Information  Interchange  -  Representation  of  Places,  States  of  the  United 
Stales,  Provinces  and  Territories  of  Canada,  Countries  of  the  World,  and  Other  Unique  Areas  for  die 
North  American  Telecommunications  System,  1988 

Telncwnmunications  •  Digital  Exchanges  and  PBXs  •  Digital  Circuit  Loopback  Test  Line,  1988 
Telecommunications  -  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  - 
Terminating  Test  Line  Capabilities  and  Access  Arrangements,  1989 

Telecommunications  -  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  - 
Upper  Layer  Protocols  for  Telecommunications  Management  Network  (TMN)  Interfaces  between 
Operations  Systems  and  Netwoik  Elements,  1993 

Telecommunications  -  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  - 
Netwoik  Tones  and  Announcements,  1989 


Telecommunications  -  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  - 
Principles  of  Functions,  Architectures,  and  Protocols  for  Telecommunications  Management 
Network  (TMN)  Interfaces,  1993 

Telecommunications  -  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  - 
Principles  of  Functions,  Architectures,  and  Protocols  for  Telecommunications  Management 
Network  (TMN)  Interfaces,  1993 

Information  Interchange  -  Representation  of  National  Security  Emergency  Preparedness- 
Telecommunicatioos  Service  Priority,  1989 

Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  -  Enhanced 
Telecommunications  Credit  Card  Physical  Characteristics  and  Numbering  Structure,  1990 
Coded  Identificetion  of  Equipment  Entities  of  the  North  American  Telecommunications  System  for 
Information  Exchange,  1990 

Telecommunications  •  OAM&P  -  A  Generic  Netwoik  Model  for  Interfaces  between  Operations 
Systems  and  Netwoik  Elements,  1990 

Telecommunications  -  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  - 
Generic  Network  Model  for  Interfaces  between  Operations  Systems  and  Network  Elements  (Managed 
Object  Class  Definitions  for  Performance  Monitoring),  1992 

Telecommunications  -  Operations,  Administration.  Maintenance,  and  Provisioning  (OAM&P)  - 
Fault  Management  Messages  for  Interfaces  between  Operations  Systems  and  Netwoik  Elements, 
1990 


Telecommunications  -  Integrated  Services  digital  Network  (ISDN)  Management  -  Basic  Rate 
Physical  Layer,  1991 

Telecommunications  -  Integrated  Services  Digital  Network  (ISDN)  Manegement  -  Primary  Rate 
Physical  Layer,  1991 

■  ISDN  Management  -  Data  Link  and  Netwoik  Layer,  1991 
-  ISDN  Management  -  Overview  and  Principles,  1991 
Telecommunications  •  Information  Interchange  -  Coded  Representation  of  the  North  American 
Telecommunication  Industry  Manufacturers,  Suppliers,  and  Related  Service  romp—i—,  1991 
Telecommunications  -  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  -  In- 
Service,  Noo-intrusive  Measurement  Device  (INMD)  •  Voice  Service  Measurements,  1991 


Telecommunications  •  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  - 
Protocols  for  Interfaces  between  Operations  Systems  in  Different  Jurisdictions.  1992 
Telecommunications  -  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  - 
Management  of  Functions  for  Signaling  System  No.  7  (SS7)  Netwoik  Interconnections,  1992 
Telecommunications  •  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  • 
Extension  to  Generic  Network  Model  for  Interfaces  between  Operations  Systems  across 
Jnriadktiooal  Boundaries  to  Support  Fault  Management,  1992 

Telecommunications  -  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  - 
Services  for  Interfaces  between  Operation  Systems  across  Jurisdictional  Boundaries  to  Support  Fault 
Management,  1992 

Telecommunications  -  Operations,  Administration,  Maintenance,  and  Provisioning  (OAM&P)  - 
Performance  Management  Functional  Area  Services  for  Interfaces  between  Operations  Systems  and 
Netwoik  Elements,  1992 


Telecommunications  -  Digital  Hierarchy  •  Layer  1  In-Service  Digital  Transmission  Performance 
Monitoring,  1993 
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UNCLASSIFIED 


ANSI  T1 .233  TslsmutenalrtelniM  -  Operations,  Administration,  M  stolen  mca.  aad  Provisioning  (OAMAP)  - 

.  Security  faumwrt  for  —ImUmm  Management  Nstwmk  (TMN)  Interfaces,  1993 

ANSI  T1 309  Telecommunication*  -  Digital  Circuit  MoltyUcation  Equipment  -  Interface  Functional  aad 

Performance  Specification,  1991 

ANSI  T1 J12  Telecommunication*  •  Voice  Packetization  •  Packed  zed  Voice  Protocol.  1991 

ANSI  T1314  Digital  Processing  of  Video  Signal*  -  Video  Coder/Decoder  for  Andiovienal  Servicee  at  36  to  1,536 

kbit/*,  1991 

ANSI  T1.401  Telecommunications  •  Interface  between  Carrier*  and  Customer  Installation*  ■  Analog  Voice-grade 

Switched  Access  Lines  Using  Loop-Start  and  Ground-Start  Signaling.  1993 
ANSI  T1.403  Integrated  Services  Digital  Network  -  Carrier-to-Customer  Installation  •  DS1  Metallic  Interface. 

1989 

ANSI  T1.404  Telecommunications  -  Carrier-tc-Customer  Installation  -  DS3  Metallic  Interface  Specification, 

1989 

ANSI  T1.405  Telecommunications  -  Interface  between  Carrier*  and  Customer  Installations  -  Analog  Voice-grade 

Switched  Access  Using  Loop  Reverse  Battery  Signaling,  1989 
ANSI  T1.407  Telecommunications  -  Interface  between  Carriers  and  Customer  Installation*  -  Analog  Voice-grade 

Special  Access  Lines  Using  Customer  Installation  Provided  Loop-Start  Supervision,  1990 
ANSI  T1.406  Telecommunications  -  ISDN  Primary  Rate  -  Customer  Installation  Metallic  Interfaces  Layer  1 

Specification,  1990 

ANSI  T1.409  Telecommunications  -  Interface  between  Carriers  and  Customer  Installations  -  Analog  Voice-grade 

Special  Access  Lines  Using  E&M  Signaling,  1991 

ANSI  T1.410  Telecommunications  -  Carrier-to-Customer  Metallic  Interface  -  Digital  Data  at  64  kbit/s  and 

Subrates,  1992 

ANSI  T1301  Telecommunications  -  Network  Performance  Standards  -  Tandem  Encoding  Limits  for  32  kbit/s 

Adaptive  Differential  Pulse-Code  Modulation  (ADPCM),  1988 

ANSI  T1302  T.w«.mn.r*iniH  -  System  M-NTSC  Television  Signals  -  Network  Interface  Specifications  and 

Performance  Parameters,  1988 

ANSI  T1303  Telecommunications  -  Network  Performance  Parameters  for  Dedicated  Digital  Services  -  Definitions 

and  Measurement  Methods,  1989 

ANSI  T1304  Telecommunication*  -  Packet-Switched  Data  Communications  Service  -  Performance  Parameters, 

1989 

ANSI  T1304b  Telecommunications  -  Packet-Switched  Data  Communications  Service  -  Performance  Objective. 

1993 

ANSI  T1305  Telecommunications  •  Advanced  Digital  Program  Audio  Services  -  Analog  Interface  and 

Performance,  1989 

ANSI  T1305*  Telecommunications  -  Packet -Switched  Data  Communicaiioos  Service  -  Performance  Mesautament 

Methods,  1991 

ANSI  T1306  Telecommunications  -  Switched  Exchange  Access  Network  Transmission  Specifications,  1989 

ANSI  T1306*  Telecommunication*  -  Network  Performance  -  Transmission  Specifications  for  Switched  Exchange 

Access  Network  (Absolute  Round-Trip  Delay),  1992 

ANSI  T1307  Telecommunication*  -  Network  Performance  -  Parameters  for  Circuit  Switched  Digital  Services  - 

Definitions  and  Measurements,  1990 

ANSI  T1308  Telecommunications  -  Network  Performance  -  Lon  Plan  for  Evolving  Digital  Networks,  1992 

ANSI  T1 508a  Telecommunications  -  Network  Performance  -  Loss  Plao  for  Evolving  Digital  Networks,  1993 

ANSI  T1.601  Integrated  Services  Digital  Network  -  Basic  Access  Interface  for  Uae  on  Metallic  Loope  for 

Application  on  the  Network  Side  of  the  NT  (Layer  1  Specification),  1992 
ANSI  T1.602  Telecommunication*  -  Integrated  Service*  Digital  Network  (ISDN)  -  Date-link  Layer  Signaling 

Specification  for  Application  at  the  User-Network  Interface,  1989 
ANSI  Tl. 603  Telecommunications  -  Minimal  Set  of  Bearer  Service*  for  the  ISDN  Primary  Rate  Interface.  1990 

ANSI  T1.604  Telecommunication*  •  Minimal  Set  of  Bearer  Services  for  the  ISDN  Basic  Rale  Interface,  1990 

ANSI  T1.6Q5  Integrated  Services  Digital  Network  •  Basic  Access  Interface  at  S  and  T  Reference  Points  (Layer  1 

Specification),  1991 

ANSI  T1.606  Telecomm  unications  -  Integrated  Services  Digital  Network  (ISDN)  -  Architectural  Framework  and 

Service  Description  for  Frame-Relaying  Bearer  Service,  1990 

ANSI  T1.606#  Telecommunications  •  Integrated  Services  Digital  Network  (ISDN)  -  Architectural  Framework  and 

Service  Description  for  Frame-Relaying  Bearer  Service  (Congestion  Management  aod  Frame  Sire), 
1992 

ANSI  Tl  ,606b  Telecommunication*  -  Integrated  Services  Digital  Network  (ISDN)  •  Architectural  Framework  and 

Service  Description  for  Frame-Relaying  Bearer  Service  (Network-to-Network  Interface 
Requirements),  1993 

ANSI  T1.607  Telecommunication*  •  Integrated  Service*  Digital  Network  (ISDN)  •  Layer  3  Signaling  Specification 

for  Circuit-Switched  Bearer  Service  for  Digital  Subscriber  Signaling  System  Number  1. 1990 
ANSI  T1.608  Telecommunications  -  Integrated  Services  Digital  Network  (ISDN)  •  Signaling  Specification  for 

X.23  Packet-Switched  Beam  Service  for  Digital  Subecribsr  Signaling  System  Number  1, 1991 
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ANSI  T1.609  Telecommunications  -  Interworking  between  the  ISDN  User-Network  Interwork  Interface  Protocol 

and  the  Signaling  System  Number  7  ISDN  User  Part,  1990 

ANSI  T1.6I0  Telecommunications  •  Digital  Subscriber  Signaling  System  No.  1  (DSS1)  -  Generic  Procedures  for 

tbe  Control  of  ISDN  Supplementary  Services,  1990 

ANSI  T1.610a  Telecommunications  -  Digital  Subscriber  Signaling  System  No.  1  (DSS1)  •  Generic  Procedures  for 

the  Control  of  ISDN  Supplementary  Services  (Display  Procedures),  1992 
ANSI  T1.611  Telecommunications  -  Signaling  System  Number  7  (SS7)  -  Supplementary  Services  for  non -ISDN 

Subscribers,  1991 

ANSI  T1.612  Telecommunications  -  Integrated  Services  Digital  Network  (ISDN)  -  Terminal  Adaption  Using 

Statistical  Multiplexing,  1992 

ANSI  T1.613  Telecommunications  •  Digital  Subscriber  Signaling  System  No.  1  (DSS1)  ISDN  Call  Waiting,  1991 

ANSI  T1.614  Telecommunications  -  Packet-Mode  Bearer  Service  Category  Description,  1991 

ANSI  T1.615  Telecommunications  -  Digital  Subscriber  Signaling  System  No.  1  (DSS1)  -  Layer  3  Overview,  1992 

ANSI  T1.616  Telecommunications  -  Integrated  Services  Digital  Network  (ISDN)  -  Call  Hold  Supplementary 

Services,  1992 

ANSI  T1.617  Integrated  Services  Digital  Network  -  DSS1  -  Signaling  Specification  for  Frame  Relay  Bearer 

Service,  1991 

ANSI  T1.618  Integrated  Services  Digital  Network  •  Core  Aspects  of  Frame  Protocol  for  Uae  with  Frame  Relay 

Bearer  Service  for  Digital  Subscribers  Signaling  System  Number  1  (DSS1),  1991 
ANSI  T1.619  Telecommunications  -  Integrated  Services  Digital  Network  (ISDN)  -  Multi-Level  Precedence  and 

Presumption  (MLPP)  Service  Capability,  1991 

ANSI  T1.620  Telecommunications  -  Integrated  Services  Digital  Network  (ISDN)  -  Circuit-Mode  Bearer  Service 

Category  Description,  1991 

ANSI  T1.621  Telecommunications  -  Integrated  Services  Digital  Network  (ISDN)  -  Uscr-to-User  Signaling 

Supplementary  Service,  1992 

ANSIT1.623  Telecommunications  -  Digital  Subscriber  Signaling  System  Number  1  (DSS1)  -  Signaling 

Specification  for  die  User  Signaling  Bearer  Service,  1993 

ANSI  T1.624  Telecommunications  -  Broadband  ISDN  User-Network  Interfaces  -  Rates  and  Formats  Specifications. 

1993 

ANSI  T1.625  Telecommunications  -  Integrated  Services  Digital  Network  (ISDN)  -  Calling  Line  Identification 

Presentation  and  Restriction  Supplementary  Service  a,  1993 
ANSI  T1.626  Telecommunications  -  Switched -Computer  Applications  Interface  (SCAI).  1993 

ANSI  Tl. 627  Telecommunications  -  Broadband  ISDN  -  ATM  Layer  Functionality  and  Specification.  1993 

ANSI  T1.628  Telecommunications  -  Routing,  Bridging,  and  Transfer  of  Emergency  Service  Calls  (RBTESC), 

1993 

ANSI  T1.629  Telecommunications  -  Broadband  ISDN  •  ATM  Adaptation  Layer  3/4  Common  Part  Functions  and 

Specification,  1993 

ANSI  T1.630  Telecommunications  -  Broadband  ISDN  -  ATM  Adaptation  Layer  for  Constant  Bit  Rale  Services 

Functionality  and  Specification,  1993 

ANSI  T1.631  Telecommunications  -  Signaling  System  No.  7  (SS7)  -  High  Probability  of  Completion  (HPC) 

Network  Capability,  1993 

ANSI  X3/TR-7-89  Information  Processing  Systems  Technical  Report  -  User  Documentation  for  Consumer  Software 
Packages,  1989 

ANSI  X3/TR-8-89  Information  Processing  Systems  Technical  Report  -  Real-Time  Extensions  for  PL/1, 1989 
ANSI  X3/TR-11-92  Information  Processing  Systems  Technical  Report  -  IRDS  Support  for  Naming  Convention 
Validation  (NCV),  1992 

ANSI  X3/TR-12-93  Information  Processing  Systems  Technical  Report  •  Repository  Context  Information  Resource 
Dictionary  System  (IRDS)  Reference  Model,  1993 

ANSIX3.1  Information  Systems  •  Data  Transmission  -  Synchronous  Signalling  Rates,  1987  (Reaffirmed  in 

1992)  (FIPS  22-1) 

ANSI  X3.4  Coded  Character  Sets  -  7-Bit  American  National  Standard  Code  for  Information  Exchange  (7-Bit 

ASCII),  1986  (Reaffirmed  in  1992)  [ISO  646] 

ANSIX3.9  Programming  Language  FORTRAN,  1978  (Reaffirmed  in  1989)  (ISO  1539) 

ANSI  X3.15  Bit  Sequencing  of  the  American  National  Standard  Code  for  Information  Exchange  in  Serial-By-Bit 

Data  Transmission,  197  (Reaffirmed  in  1990)  (FIPS  16-1;  ISO  1177)  (revision  in  process) 

ANSI  X3.23  Programming  language  COBOL,  1985  (Reaffirmed  in  1991)  (ISO  1989) 

ANSI  X3.23a  Programming  Language  Intrinsic  Function  Module  for  COBOL,  1989  (Reaffirmed  in  1991) 

ANSI  X3.23b-199x  Correction  Amendment  to  American  National  Standard  COBOL  ANSI  X3.23-1985[R1991]  and  ANSI 
X3.23A-1989  [R1991] 

ANSI  X3.28  Procedures  for  the  Use  of  tbe  Communications  Control  Characters  of  American  National  Standard 

Code  for  Information  Interchange  (ASCII)  in  Specified  Data  Communication  Links,  1976 
(Reaffirmed  in  1992) 

ANSI  X332  Graphic  Representation  of  the  Control  Characters  of  American  Standard  Code  for  Information 

Interchange  (ASCII),  [ISO  2047-75],  Revised  1990 
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ANSI  X3.102 
ANSI  X3.1Q5 
ANSI  X3.106 

ANSI  X3. 107 
ANSI  X3. 108 

ANSI  X3.109 
ANSI  X3.U0 

ANSI  X3.113 

ANSI  X3.U3a 

ANSI  X3.122 

ANSI  X3.1223 
ANSI  X3.123 
ANSI  X3.124 

ANSI  X3.124.1 

ANSI  X3.124.2 
ANSI  X3.124J 
ANSI  X3.124.4 
ANSI  X3.129 
ANSI  X3.130 

ANSI  X3.131 
ANSI  X3.132 

ANSI  X3.133 
ANSI  X3.I34.1 
ANSI  X3.134.2 
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Code  Extension  Techniques  for  Use  with  the  7-Bit  Coded  Character  Set  of  American  National 
Standard  Code  for  Information  Interchange  (ASCII),  1974,  Revised  1990  (FIPS  33,  Withdrawn;  ISO 
2022-82]) 

Representation  of  Numeric  Values  in  Character  Strings  for  Information  Interchange,  [ISO  6093.2], 
1975,  Revised  1990 

Determination  of  the  Performance  of  Data  Communications  Systems,  1990 
Programming  Language  PL/1,  1976  (Reaffirmed  in  1993)  (ISO  6160) 

Structure  for  Formatting  Message  Headings  for  Information  Interchange  Using  the  American 
National  Standard  for  Information  Interchange  (ASCII)  for  Data  Communication  System  Control, 
1977  (Reaffirmed  in  1991) 

Programming  Language  Minimal  BASIC,  Draft  (DP  6373] 

Representation  of  Geographic  Point  Locations  for  Information  Interchange,  1986  (Reaffirmed  in 
1992) 

Advanced  Data  Communication  Control  Procedures  (ADCCP),  1979  (Reaffirmed  in  1992)  (PIPS  71) 
Informatioo  Systems  -  Programming  Language  -  PL/1  General  Purpose  Subset,  1987  (Reaffirmed  in 
1992)  (DP  6322) 

Determination  of  Performance  of  Data  Communications  Systems  that  Use  Bit  Oriented 
Communications  Control  Procedures,  1981  (Reaffirmed  in  1992) 

Information  System  •  ISO  Registration  According  to  ISO  2373,  ANSI  Sponsorship  Procedures, 
1989  [ISO  2373] 

Computer  Program  Abstracts,  1981  (Reaffirmed  in  1992) 

Information  Systems  -  Storage  Module  Interfaces,  1987  (Reaffirmed  in  1992) 

Date  Encryption  Algorithm,  1981  (Reaffirmed  in  1987) 

Programming  Language  Pascal,  1983  (MS  7183) 

Text  Information  Interchange  in  Page  Image  Format  (PIF),  1983 

Information  Systems  -  Interface  between  DTE  and  DCE  for  Operation  with  Packet-Switched  Data 
Communications  Networks  (PSDN),  or  Between  Two  DTEs,  by  Dedicated  Circuit,  1989 
Information  Systems  -  Interface  between  DTE  and  DCE  for  Operation  with  Packet-Switched  Data 
Communications  Networks  (PSDN),  or  Between  Two  DTEs,  by  Dedicated  Circuit  (NUI  and  NUI- 
Derived  Extensions),  1991 

Data  Communication  Systems  and  Services  -  User-Oriented  Performance  Parameters.  1992 
Information  Systems  -  Data  Link  Encryption,  1983  (Reaffirmed  fat  1990) 

Information  Systems  -  Data  Encryption  Algorithm  -  Modes  of  Operation.  1983  (Reaffirmed  in 

1990) 

Data  Link  Layer  Protocol  for  Local  Distributed  Dau  Interfaces  (LDDI).  August  1982  (DP) 

Information  Systems  •  Local  Distributed  Data  Interfaces  (LDDI)  -  Physical  Layer  Interface  to 
NoobrancMng  Coaxial  Cable  Bos,  1988 

Physical  Layer  Protocol  for  Local  Distributed  Data  Interfaces  (LDDI).  1982  (DP) 

Videotex/Teletext  Presentation  Level  Protocol  (North  American  PLPS),  1983  (Reaffirmed  in  1991) 
(FIPS  121)  [ISO  6937/1-2] 

Information  Systems  -  Programming  languages  -  Full  BASIC.  1987  (Reaffirmed  in  1993)  (FIPS  68- 
2)  [DP  10279] 

.Information  Systems  •  Programming  Languages  -  Modules  and  Individual  Character  Input  for  Full 
BASIC.  1989  (Reaffirmed  fat  1993)  (FIPS  68-2) 

Computer  Graphics  Metafile  (COM)  for  the  Storage  and  Transfer  of  Picture  Description  Information. 
1986  (withdrawn  and  replaced  by  ISO  8632:1990,  Parts  1-4) 

USP  Binding  of  GKS,  Draft,  1989 
Programming  Language  APL,  Draft,  1989  (DP  8485) 

Computer  Graphics  -  Graphical  Kernel  System  (GKS)  Functional  Description,  1983  (Reaffirmed  in 

1991)  (ISO  7942) 

Information  Systems  •  Computer  Graphics  -  Graphical  Kernel  System  (GKS)  FORTRAN  Language 
Binding,  1983  (Reaffirmed  in  1993)  (ISO  8651-1) 

Computer  Graphics  -  Graphical  Kernel  System  (GKS)  Pascal  Language  Binding.  1988  (ISO  8631-2) 
Con^taer  Graphics  •  Graphical  Kernel  System  (GKS)  Ada  Language  Binding,  1989  (ISO  8631-3) 
Computer  Graphics  •  Graphical  Kernel  System  (GKS)  C  Binding,  Draft,  1989  (DP  8631-4) 

Intelligent  Peripheral  Interface,  Physical  Level,  1986  (Reaffirmed  in  1992)  (ISO  9318-1] 

Intelligent  Peripheral  Interface  •  Device-Specific  Command  Set  for  Magnetic  Disks,  1986 
[ISO  9318-2] 

Small  Computer  System  Interface  (SCSI),  1986  [ISO  9316) 

Information  Systems  •  Intelligent  Peripheral  Interface  •  Device  Generic  Command  Set  for  Magnetic 
and  Optical  Diaks,  1987  [ISO  8907]  (wkbthawn  and  replaced  by  ANSI/ISO  9318-3-1990) 

Database  Language  -  NDL,  1986  (Reaffirmed  in  1992)  (FIPS  126) 

8-Bit  ASCII  Structure  and  Rulea,  Draft 

7-Bit  and  8-Bit  ASCII  Supplemental  Multilingual  Graphic  Character  Set  (ASCII  Multilingual  Set), 
Draft 
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ANSI  X3.146 
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ANSI  X3.1M 


Information  Systems  -  Database  Language  •  SQL,  1992  (FIPS  127-1)  (ISO  9075:1992) 

Information  Jystams  -  Information  Resource  Dictionary  System  (TRDS),  1988  (DIS  10027)  (FIPS 
156) 

Information  Systems  •  Information  Resource  Dictionary  System  (IRDS)  (Supplement  to  X3.138- 
1988),  1991 

Information  Systems  -  Fiber  Distributed  Data  Interface  (FDDI)  •  Token  Ring  Media  Access  Control 
(MAC),  1987  (Reaffirmed  in  1992)  (DP  9314-2) 

Information  Processing  Systems  -  Open  Systems  Interconnection  •  Connection  Oriented  Transport 
Layer  Protocol  Specification,  1986  (withdrawn  and  replaced  by  ANSI/ISO  8072-1986  and 
ANSI/ISO  8073-1991) 

Information  Systems  -  Data  Communication  Systems  and  Services  -  Measurement  Methods  for  User- 
Oriented  Performance  Evaluation,  1987  (Reaffirmed  in  1992) 

Information  Processing  Systems  -  Text  and  Office  Systems  -  Standard  Generalised  Markup  Language 
{SGML),  Draft  [ISO  8879] 

Information  Processing  Systems  -  Computer  Graphics  •  Programmer's  Hierarchical  Interactive 
Graphics  System  (PHIGS)  Functional  Description,  1988  (withdrawn  and  replaced  by 
ANSI/ISO  9592-1989,  Pans  1-3) 

FORTRAN  Language  Binding  of  the  Programmer's  Hierarchical  Interactive  Graphics  System 
(PHIGS),  1988  (withdrawn  aod  replaced  by  ANSI/ISO  9593-1-1992) 

Computer  Graphics  -  Programmer's  Hierarchical  Interactive  Graphics  System  (PHIGS)  Binding  to 
Pascal.  Draft,  1987  (DIS  9S93-2) 

Information  Processing  Systems  -  Computer  Graphics  •  Programmer's  Hierarchical  Interactive 
Graphics  System  (PHIGS)  Binding  to  Ada,  1988  (withdrawn  and  replaced  by  ANSI/ISO  9593-3- 
1992) 

Computer  Graphics  -  Programmer’s  Hierarchical  Interactive  Graphics  System  (PHIGS)  C  Language 
Binding.  Draft,  1991  (ISO  9593-4) 

Information  Systems  -  Streaming  Cartridge  and  Cassette  Tape  Drives  -  Device-Level  Interface,  1986 
Intelligent  Peripheral  Interface  -  Device  Generic  Command  Set  for  Magnetic  Tape,  1987 
(ISO  9318-4]  (not  listed  in  1994  ANSI  Catalog) 

Information  Systems  -  Fiber  Distributed  Data  Interface  (FDDI)  -  Physical  Layer  Protocol  (PHY), 
1988  (ISO  9314-1) 

Information  Systems  •  Open  Systems  Interconnection  •  Basic  Connection  Oriented  Session 
Protocol  Specification,  1987  (withdrawn  and  replaced  by  ANSI/ISO  8326-1987  and  8327-1987) 
Information  Systems  -  Programming  Languages  -  Programming  Language  C,  1989  (ISO  9899: 
1990;  FIPS-160)  (withdrawn  and  replaced  by  ANSI/ISO  9899-1990) 

Programming  Language  Extended  Pascal,  1990  [replaced  by  ANSI/IEEE  770  X3. 160-1989] 
Computer  Graphics  Interface  (CGI),  1990  [replaced  by  ISO  9636) 

Information  Systems  -  Programming  language  -  DIBOL  (revision  of  ANSI  X3. 165-1988),  1992 
Fiber  Distributed  Data  Interface  (FDDI)  >  Physical  Layer  Medium  Dependent  (PMD),  1990 
(ISO  9314-3] 

Local  Distributed  Data  Interface  (LDDi)  Star-Wired  Physical  Interface  Sublayer,  Draft,  1987  (DP) 
Information  Systems  •  Database  Language-  Embedded  SQL  (withdrawn;  now  included  in 
ANSI  X3. 133-1992) 

Information  Systems  -  Data  Communication  -  Enhanced  Small  Device  Interface  (ESDI),  1990 
(DIS  10222] 

Information  Systems  -  Data  Communication  -  Enhanced  Small  Device  Interface  (ESDI),  1991 
(enhancement  to  ANSI  X3. 170-1990) 

American  National  Standard  Dictionary  for  Information  Systems  (ANDIS),  1990  (now  includes 
X3.172a-1992) 

Information  Systems  •  Dictionary  for  Information  Systems  (Computer  Security  Glossary),  1992 
Hypermedia  and  Multimedia  Glossary,  X3K5,  new  project 

Intelligent  Peripheral  Interface  Device  •  Specific  Command  Set  for  Magnetic  Tapes,  1990.  [ISO 
9318-5] 

Intelligent  Peripheral  Interface,  Device  -  Generic  Command  Set  for  Communications,  1990, 
(ISO  9318-7] 

Information  Systems  -  Packet-switched  Signalling  System  Between  Public  Networks  Providing  Data 
Transmission  Service,  1990 

Information  Systems  -  Packet-switched  Signalling  System  Between  Public  Networks  Providing  Data 
Transmission  Service  (NUI  Utility  Extensions  and  Format  Constraints),  1991 
Information  Systems  -  High-Performance  Parallel  Interface  (HPPI),  1991 

Information  Systems  -  Fiber  Distributed  Data  Interface  (FDDI)  -  Single  Mode  Physical  Layer  Medium 
Dependent  (SMF-PMD)  (CD  9314-4),  1993 

Information  Systems  •  Information  Resource  Dictionary  Systems  •  IRDS  Services  Interface,  1992 
Information  Systems  •  Fiber  Distributed  Data  Interface  (FDDI)  -  Hybrid  Ring  Control  (HRC),  1992 
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ANSI  X3.189  Information  Systems  -  Interface  BOm  DTE  and  DCE  for  TMuh  Operating  in  the  Packat  Mode 

tad  Accessing  i  Packet-Switched  Public  Deta  Network  Through  Switched  Access,  1991 
ANSI  X3.190  Information  Technology  •  Text  and  Office  Systems  •  Conformance  Testing  for  SGML  Systems, 

1992 

ANSI  X3.195  Information  Systems  -  Inform stion  Resource  Dictionary  System  (IRDS)  -  Export/Import  File 

Format,  1991 

ANSI  X3.196  Computer  Graphics  -  X  Window  System  Data  Stream  Definition,  Draft 

ANSI  X3.198  Programming  Language  -  FORTRAN  •  Extended,  1992 

ANSI  X3.201  Information  Systems  -  Intelligent  Peripheral  Interface  (IPX)  -  Enhanced  Physical  Level,  1992 

ANSI  X3.209  Information  Systems  •  Optical  Character  Recognition  (OCR)  -  Matrix  Character  Sets  for  OCR-MB, 

1991 

ANSI  X3.210  Information  Systems  •  High-Performance  Parallel  Interface  -  Framing  Protocol  (HPPI-FP),  1992  - 

ANSI  X3.21S  Programming  Language  FORTH,  DRAFT 

ANSI  X3.216  Information  Processing  Systems  -  Data  Communications  -  Structure  and  Semantics  of  the  Domain 

Specific  Part  (DSP)  of  the  OSI  Network  Service  Access  Point  (NSAP)  Address,  1992 
ANSI  X3.218  Information  Systems  -  High-Performance  Parallel  Interface  (HPPI)  -  Encapsulation  of  ISO  8802-2 

(IEEE  Std  802.2)  Logical  Link  Control  Protocol  Data  Units  (HPPI-LE),  1993 
ANSI  X3.219  X  Window  System  Data  Stream  Definition,  Part  IV:  Mapping  onto  Open  Systems  Interconnection 

ANSI  X3.222  Information  Systems  -  High-Performance  Parallel  Interface  (HPPI)  -  Physical  Switch  Control  (HPPI- 

SC),  1993 

ANSI  X3.226  Programming  Language  Common  LISP,  Draft 

ANSI  X3.228  X.25  Data  Transfer  Phase  (DTP)  Procedures  for  Operation  with  Frame  Relay,  1993 

ANSI  X3.229-199x  FDDL  Part  6:  Station  Management  (SMT)  Standard,  Revision  7.2 

ANSI  X3.238  Programming  Language  DATABUS,  Draft 

ANSI  X3H4.6  Technical  Report  on  Model  Unification  for  Data  Repositories 

ANSI  X3S3.7  X.23  Data  Transfer  Phase  Procedures  for  Operating  the  Packet  Layer  Transfer  Phase  of  X2S 

ANSI  X3T9.5  FDD1  Follow-On  Local  Area  Network  -  Physical  Medium  Dependent  (FPOL-PMD),  new  project, 

10  May  1991 

ANSI  X3T9.5  FDDI  Follow-On  Local  Area  Network  -  Physical  Layer  Protocol  (FFOL-PHY).  new  project, 

10  May  1991 

ANSIX3T9.5  FDDI  Follow-On  Local  Area  Network  -  Service  Multiplexer  (FFOL-SMUX).  new  project, 

10  May  1991 

ANSIX3T9.5  FDDI  Follow-On  Local  Area  Network  -  Asynchronous  Media  Access  Control  (FFOL-AMAC),  new 

project.  May  10,  1991 

ANSIX3193  FDDI  Follow-On  Local  Area  Network  -  Isochronous  Media  Access  Control  (FFOL-IMAC),  new 

project.  May  10.  1991 

ANSI  X3T9.5  FDDI  Follow -On  Local  Area  Network  •  Station  Management  (FFOL-SMT),  new  project, 

10  May  1991 

ANSI  X3V1.4  Voice  Messaging  over  MOTTS  ISCVDIS  10021 

ANSI  X3V1.9  Standard  User  Interface  to  Voice  Messaging 

ANSI  X3  682-D  Domestic  Public/Private  X.23  Network  Interworking,  Draft 

ANSI  X930  Public  Key  Cryptography,  Part  2,  1993 

ANSI  X12  Series  Electronic  Data  Interchange  (ISO  9733)  (Parts  1  to  50).  1992 

ANSI  Y14.26M  Digital  Representation  for  Communication  of  Product  Definition  Data,  Draft,  1989 

ANSI  ZJ9-50-1992  Information  Retrieval  •  Application  Service  Definition  and  Protocol  Specification  for  Open 

Systems  Interconnection,  1992  (renamed  ANSI/NISO  Z39.50-1992) 

ANSI  ZJ93041A426  Implementors  Group  Profile 

EIA-232C  Interface  Between  Data  Terminal  Equipment  and  Data  Communication  Equipment  Employing  Serial 

Binary  Data  Interchange,  Third  Edition  (also  known  as  R5-232C) 

EIA-232D  Interface  Between  Data  Terminal  Equipment  and  Dali  Communication  Equipment  Employing  Serial 

Binary  Data  Interchange,  Fourth  Edition  (also  known  is  RS-232D) 

FED-STD 1041  Interface  Between  Deta  Terminal  Equipment  (DTE)  and  Data  Circuit-Terminating  Equipment  (DTE) 

for  Operation  with  Pack-Switched  Data  Communications  Network,  National  Communications 
System 

HFS/ANSI  100-1988  Human  Factors  Engineering  of  Video  Display  Terminal  Workstation  Standard,  1988 

IEEE  610  IEEE  Standard  Computer  Dictionary  Compilation  of  IEEE  Standard  Computer  Glossaries.  1990 

IEEE  610.2  IEEE  Standard  Glossary  Computer  Applications  Terminology,  1987 

IEEE  6103  IEEE  Standard  Glossary  of  Modeling  and  Simulation  Terminology,  1989 

IEEE  6104  IEEE  Standard  Glossvy  of  Image  Processing  and  Pattern  Recognition  Terminology,  1990 

IEEE  6103  IEEE  Standard  Glossary  of  Data  Management  Terminology.  1990 


Appendix  H 


H-23 

UNCLASSIFIED 


Military  Standards 


UNCLASSIFIED 


IEEE  610.6 
IEEE  610.12 
IEEE  610.12A 

IEEE  610.12B 

IEEE  610.12H 

IEEE  610.13 
IEEE  660 
IEEE  662 
IEEE  696 
ANSI/IEEE  729 
ANSMEEE  730 
IEEE  754 
IEEE  770 
IEEE  796 
IEEE  802 
IEEE  802.  IB 
IEEE  802.1D-1993 

IEEE  802.1E 


IEEE  802. li 
IEEE  802.1k 
IEEE  802.1m 
IEEE  8023-1993 

IEEE  802 3h 
IEEE  80231 

IEEE  8023k 

IEEE  80231 

IEEE  8023p 
IEEE  802 3q 


IEEE  8024b 

IEEE  8023c 

IEEE  8023m 
IEEEP8023q 

IEEE  802.6 

IEEE  802.6c 
IEEE  S02.6d 
IEEE  802.6f 
IEEE  8023k 

IEEE  802.7 
IEEE  P802.10A 


IEEE  Standard  Glossary  of  Computer  Graphics  Terminology,  1991 
IEEE  Standard  Glossary  of  Software  Engineering  Terminology  ,  1990 

IEEE  Standard  Glosaary  of  Software  Engineering  Terminology  -  ASCII  Version.  3  1 /2-inch  Diskette 
with  Soft  bound  Text,  1990 

IEEE  Standard  Glossary  of  Software  Engineering  Terminology  -  ASCII  Version,  5  1/4-inch 
Diskettes  with  Soft  bound  Text,  1990 

IEEE  Standard  Glossary  of  Software  Engineering  Terminology  -  HyperCard  Stack,  diskette  only 

(HyperCard  v.1.2  and  up),  1990 

IEEE  Standard  Glossary  of  Computer  Languages,  1993 

IEEE  Standard  for  Semiconductor  Memory  Test  Pattern  Language,  1986,  reaffirmed  1991 

IEEE  Standard  Terminology  for  Semiconductor  Memory,  1980 

IEEE  Standard  696  Interface  Devices,  1983,  reaffirmed  1991 

IEEE  Standard  Glossary  of  Software  Engineering  Terminology,  1983 

IEEE  Standard  for  Software  Quality  Assurance  Plans,  1989 

IEEE  Standard  for  Binary  Floating-Point  Arithmetic,  1985,  reaffirmed  1991 

Programming  Language  Pascal,  1990 

IEEE  Standard  Microcomputer  System  Bus,  1983  (reaffirmed  1988) 

IEEE  Standards  for  Local  and  Metropolitan  Area  Networks:  Overview  and  Architecture,  1990 
IEEE  Standards  for  Local  and  Metropolitan  Area  Networks:  LAN/MAN  Management,  1992 
Information  Technology  -  Telecommunications  and  Information  Exchange  Between  Syatems  -  Local 
Area  Networks  -  Media  Access  Control  (MAC)  Bridges  (same  as  ISO/IEC  10038:1993) 

IEEE  Standards  for  Local  and  Metropolitan  Area  Networks:  Supplement  to  Carrier  Sense  Multiple 
Access  with  Collision  Detection  (CSMA/CD)  Access  Method  and  Physical  Layer  Specifications: 
Layer  Management  (Section  5).  1990 

IEEE  Supplement  to  Media  Access  Control  (MAC)  Bridges.  Fiber  Distributed  Data  Interface  (FDDI), 
1992 

LAN/MAN  (Local  Area  Network/Metropolitan  Area  Network)  Management:  Standard  for  Discovery 
and  Dynamic  Control  of  Event  Forwarding  (supplement  to  802.1B),  1993 
Standard  for  System  Load  Protocol  Supplement-  Managed  Object  Definitions  and  Protocol 
Implementation  Conformance  Statement  (PICS)  Proforma  (supplement  to  802.1B),  1993 
Information  Technology  -  Local  and  Metropolitan  Area  Networks  -  Part  3:  Carrier  Sense  Multiple 
Access  with  Collision  Detection  (CSMA/CD)  Access  Method  and  Physical  Layer  Specifications 
(same  as  ISO/IEC  8802-3:1993) 

IEEE  Standards  for  Local  and  Metropolitan  Area  Networks:  System  Load  Protocol.  1990 
IEEE  Supplement  to  Carrier  Sense  Multiple  Access  with  Collision  Detection  (CSMA/CD)  Access 
Method  and  Physical  Layer  Specifications:  System  Considerations  for  Multisegment  10  Mh/s 
Baaebaod  Networks  (Section  13)  and  Twisted-Pair  Medium  Attachment  Unit  (MAU)  and  Baseband 
Medium.  Type  1QBASE-T  (Section  14),  1990 

TKFP  Standards  for  Local  and  Metropolitan  Area  Networks:  Supplement  to  Canter  Sense  Multiple 
Access  with  Collision  Detection  (CSMA/CD)  Access  Method  and  Physical  Layer  Specifications: 
Layer  Management  for  10  Mb/s  Baseband  Repeaters  (Section  19),  1992 

IEEE  Supplement  to  Carrier  Sense  Multiple  Access  with  Collision  Detection  (CSMA/CD)  Access 
Method  and  Physical  Layer  Specifications:  Type  1QBASE-T  MAU  Protocol  Implementation 
Conformance  Statement  (PICS)  Proforma,  1992 

Standard  for  Carrier  Sense  Multiple  Access  with  Collision  Detection  (CSMA/CD)  Access  Method: 
Layer  Management  for  tO  Mb/s  Baseband  Medium  Attachment  Units  (MAU*),  1993 
Standard  for  Carrier  Sense  Multiple  Access  with  Collision  Detection  (CSMA/CE)  Access  Method: 
Guidelines  for  the  Development  of  Managed  Objects  (GDMO)  (ISO  10164-4)  Format  for  Layer 
Managed  Objects,  1993 

IEEE  Supplement  to  Token-Passing  Bus  Access  Method  and  Physical  Layer  Specifications: 
Enhancements  for  Physical  Layer  Diversity,  1992 

IEEE  Supplement  to  Token-Passing  Bus  Access  Method  and  Physical  Layer  Specifications: 
Recommended  Practice  for  Dual  Ring  Operation  with  Wrapback  Reconfiguration,  1991 
Supplement  to  ISO/IEC  10038:1993,  Source  Routing,  1993 

Standard  for  Information  Technology-Local  and  Metropolitan  Area  Networks-Part  5:  Token  Ring 

Access  Method  and  Physical  Layer  Specification-  Media  Access  Control  Revision 

IEEE  Standards  for  Local  and  Metropolitan  Area  Networks:  Distributed  Queue  Dual  Bus  (DQDB) 

Subnetwork  of  a  Metropolitan  Area  Network  (MAN),  1990 

Standard  for  DS1  Physical  layer  Convergence  Procedures  for  802.6  MAN,  1993 

Standard  for  SONET  (SDH)  Based  Physical  Layer  convergence  Procedures  for  802.6  MAN,  1993 

Standard  for  Conformance  Statement  for  the  802.6  Base  Standard,  1993 

Supplement  to  Media  Access  Control  (MAC)  Bridges:  IEEE  Standard  802.6  Distributed  Queue  Dual 

Bus  Subnetwork  of  Metropolitan  Area  Network  (MAN),  1992 

IEEE  Recommended  Practices  for  Broad  band  Local  Area  Networks,  1989 

Interoperable  LAN  Security  (SILS)  -  The  Model  (PAR  approved  5/90) 


Appendix  H 


H-24 


Military  Standards 


UNCLASSIFIED 


UNCLASSIFIED 


IEEE  S02.lt® 

IEEE  P802.10C 
IEEE  P802.10D 
IEEEP802.11 

IEEE  828 
ANSMEEE  829 
ANSWEEE830 
IEEE  896.2-1991 
IEEE  8963 
IEEE  8963 
IEEE  982.1 
IEEE  9823 
ANSI/IEEE  983 
ANSI/IEEE  990 
ANSI/IEEE  1002 
IEEE  1003 

IEEE  P1003.0 
IEEE  1003.1 
IEEE  P 1003.1 

IEEE  PI 003.1 /LIS 
IEEE  P1003.1a 
IEEE  1003.1b 
IEEE  1003.1c 
IEEE  1003.  Id 
IEEE  P10Q3.1e 
IEEE  P1003.1f 
IEEE  10Q3.lt 

IEEE  1003.2 
IEEE  1003.2a 
IEEE  P10Q3.2C 
IEEE  P1003.2d 

IEEE  10033 

IEEE  10033.1 
IEEE  P1003.3.2 
IEEE  1003.4 
IEEE  P1003.4t 
IEEE  P1003.4b 
IEEE  10033 


IEEE  P10033b 
IEEE  P1003.6 
IEEE  P1003.6.1 
IEEE  P1003.63 
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IEEE  Standards  for  Local  and  Metropolitan  Area  Networks:  Standard  for  Intaroparabts  LAN  Security 
(SILS),  Part  B:  Secure  Data  Excbante,  1992 
SILS  -  Key  Management  [PAR  approved  S/90) 

SILS  -  Security  Management  [PAR  approved  S/90] 

Standard  for  Wireless  Medium  Access  Control  (MAC)  and  Physical  Layer  (PHY)  Specifications  [PAR 
approved  March  21.  1991] 

Standard  for  Software  Configuration  Management  Plans,  1990 

IEEE  Standard  for  Software  Test  Documentation,  1983  (Standard  reaffirmed  March  21. 1991]) 

IEEE  Guide  to  Software  Requirements  Specifications,  1984  (Revision  underway) 

Futurebus-f,  Physical  Layer  and  Profile  Specifications,  1993 

Recommended  Practices  for  Futurebus-f,  1993 

Standard  for  Futurebus-f,  Profile  M  (Military),  1993 

IEEE  Standard  Dictionary  of  Measures  to  Produce  Reliable  Software,  1988 

IEEE  Guide  for  the  Use  of  IEEE  Standard  Dictionary  of  Measures  to  Produce  Reliable  Software,  1988 

IEEE  Guide  for  Software  Quality  Assurance  Planning,  1986 

IEEE  Recommended  Practice  for  Ada  as  a  Program  Design  language,  1986 

IEEE  Standard  Taxonomy  for  Software  Engineering  Standards,  1987,  REAFFIRMED  1992 

IEEE  Standard  Interpretations:  IEEE  Standard  Portable  Operating  System  Interface  for  Computer 

Environments,  1988 

PCSIX  Guide,  Draft  IS,  balloted  July  1992 

POSIX,  approved  as  IEEE  Std.  1003.1-1988  and  revised  September  1990 

Language  Independent  Specifications,  as  IEEE  Std.  1003.1-1990,  ISO  9945-1  and  FIPS  152-2,  Draft 
3,  May  1992 
See  IEEE  P1372 

System  API  Extensions,  Draft  7,  balloted  late  1992 

Real-Tune  Extensions,  Draft  13x  recirculated.  October  1992  (formerly  IEEE  1003.4) 

Threads,  Draft  7  recirculated  May  1992  (formerly  IEEE  P10Q3.4a) 

Extensions  to  .4,  Draft  S,  September  1992,  1st  ballot,  IQ  1993  (formerly  IEEE  P1003Ab) 

System  API  Security  Addendum  (formerly  IEEE  PI 003 .6.1) 

Transparent  File  Access  (TFA),  Draft  6.  2Q  1992  (formerly  IEEE  P10033) 

Protocol  Independent  Network  Interfaces,  Draft  1.4,  balloting  planned  for  2Q  1993  (formerly  IEEE 
P1003.12) 

Shell  and  Utilities,  approved  September  7,  1992 

User  Portability  Interfaces,  spproved  as  part  of  IEEE  Std.  1003.2 

Shell  and  Utility  Security  Addendum  (formerly  IEEE  P1003.6.2) 

POSIX,  Part  2:  Shell  and  Utilities  -  Amendment:  Batch  Environment  (PAR  approved)  (formerly 
IEEE  P1003.15a) 

Test  Methods,  IEEE  10033-1991  approved  March  21,  1991.  ISO  standard  proposed;  international 
ballot  initiation  pending  (see  IEEE  2003) 

Test  Methods  for  POSIX. 1,  approved  December  1992  (see  IEEE  2003.1) 

Test  Methods  for  Measuring  Conformance  to  POSIX,  Draft  8  balloted  4Q  1992  (sea  IEEE  20033) 
Real-Time  Extensions,  Draft  13x  recirculated,  October  1992  (see  IEEE  1003.1b) 

Threads,  Draft  7  recirculated  May  1992  (see  IEEE  1003.1c) 

Extensions  to  .4,  Draft  5,  September  1992,  1st  ballot,  IQ  1993  (see  IEEE  1003.1d) 

POSIX  Ada  Language  Binding,  approved  June  1992,  [PAR  approved  for  revision  October  1993.  The 
new  title  will  be  POSIX  Ada  Language  Interfaces  -  tat  1:  Binding  for  System  Application  Program 
Interface  (API)] 

Ada  Language  (Real  Time)  Bindings;  ballot  planned  for  December  1993  (formerly  IEEE  P10Q330) 
Security  Extensions.  Draft  12,  October  1991  (see  IEEE  P1003.1e  and  IEEE  P10033c) 

System  API  Security  Addendum 
Shell  and  Utility  Security  Addendum 

Administered  Systems  (name  changed  from  System  Administration  Interface),  Work  is  being 
’sliced*  into  ballotable  partitions  which  will  be  balloted  separately  in  IQ  1993  (aee  ffiRR  P1387) 
Amendment  1:  Print  Administration,  [PAR  approved,  Mach  19, 1992],  Draft  (see  IEEE  P1387.4) 
Amendment  2:  Software  Administration  [PAR  approved,  March  19,  1992),  ballot  May  1992  (see 
IEEE  P1387.2) 

Amendment  3:  User  Administration  [PAR  approved  October  1993)  (see  IEEE  P13873) 

Transparent  File  Access  (TFA),  Draft  6, 2Q  1992  (see  IEEE  PI 003.  ID 

FORTRAN  77  Language  Binding,  Draft  11  approved  June  1992 

Supercomputing  Application  Environment  Profile  (AEP),  Draft  11.  September  1992 

POSIX  Based  Transaction  Processing  Applications  Environment  Profile,  PAR  approved  1993 

(withdrawn) 

Protocol  Independent  Network  Interfaces,  Draft  1.4,  balloting  planned  for  2Q  1993  (see 
IEEE  P1003.1g) 
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Real-Time  AEP,  Draft  3,  April  1992.  ballot  May  1992 
Multiprocesaing  AEP,  Draft  3,  7  April  1992 

POSIX  Batch  Environment  Amendment!,  balloting  of  Draft  10,  November  1992  (to  be  revised) 
POSIX,  Part  2:  Shell  and  Utilities  -  Amendment:  Batch  Environment  (PAR  approved)  (tee 
IEEE  P1003.2d) 

C  Binding  for  POSIX.  1,  Draft  2.  May  1992,  ballot  doted  18  September  1992  [PAR  withdrawn 
October  1991] 

Amendment  1:  System  API  Extensions  [PAR  approved,  March  19,  1992]  [PAR  withdrawn 
October  1991] 

Directory  Services  API,  Draft  4,  tpproved  March  1993  (see  IEEE  P1224.2) 

POSIX  Platform  Profile,  Draft  6,  May  1992,  balloted  4Q  1992 

POSIX  FORTRAN  90  Language  Binding,  initiated  July  1992  [PAR  withdrawn  October  1991] 

Ada  Language  (Real  Time)  Bindings;  ballot  planned  for  December  1993  (see  IEEE  P10033b) 
POSIX,  Part  1:  System  Application  Programming  Interface  (API)  -  Amendment:  Real-Time 
Distributed  Systems  Communications  (PAR  approved) 

Guide  to  the  POSIX  Open  Systems  Environment  -  A  Security  Framework  (PAR  approved) 

OSI  Abstract  Data  Maniuplation  API  (LIS),  1993 

Directory  Services  Application  Programming  Interface  (API)  -  Language  Independent 
Specification  approved  March  1993  (formerly  IEEE  P1003.17) 

Language  Independent  Specifications,  as  IEEE  Std.  1003.1-1990,  ISO  9943-1  and  FIPS  132-2, 
Draft  3.  May  1992  (formerly  IEEE  PI 003. 1/US) 

Administered  Systems  (name  changed  from  System  Administration  Interface);  work  is  being 
'sliced*  into  ballotable  partitions  which  will  be  balloted  separately  in  IQ  1993  (formerly 
IEEE  P1003.7) 

Amendment  2:  Software  Administration  [PAR  approved,  March  19,  1992],  ballot  May  1992 
(fosmeriy  IEEE  P1003.72) 

Amendment  3:  User  Administration  [PAR  approved  October  1993]  (formerly  IEEE  P1003.7.3) 
Amendment  1:  Print  Administration,  [PAR  approved,  March  19,  1992],  Draft  3  mock  ballot, 
2Q  1992  (formerly  IEEE  N003.7.1) 

Test  Methods,  IEEE  10033-1991  sp proved  March  21,  1991.  ISO  standard  proposed;  international 
ballot  initiation  pending  (formerly  IEEE  10033) 

Test  Methods  for  Measuring  Conformance  to  POSIX  -  Part  1:  System  Interfaces,  approved 
December  1992  (formerly  IEEE  10033.1) 

Test  Methods  for  Measuring  Conformance  to  POSIX,  Draft  8  balloted  4Q  1992  (formerly 
IEEE  1003.3.2) 

IEEE  Standard  for  Software  Unit  Testing,  1987 

MU  Standard  for  Software  Verification  and  Validation  Plans,  1987  [PAR  approved  for  Standard 
Revision.  March  19.  1992] 

MJ.  Recommended  Practice  for  Software  Design  Descriptions,  1987 
IEEE  Guide  to  Software  Design  Descriptions,  1993 
1KER  Standard  for  Software  Reviews  and  Audits,  1988 
lEEF.  Guide  to  Software  Configuration  Management,  1988 

Standard  for  Classification  of  Software  Anomalies  (formerly  entitled  Classification  of  Software 
Errors/Faults/Failures ) 

Software  Productivity  Metrics,  1992 

M.P.  Standard  for  Software  Project  Management  Plans,  1987  [PAR  approved  for  revision  October 
1993] 

Guide  for  Software  Project  Management  Plans  [PAR  WITHDRAWN  March  21, 1991] 

Software  Verification  and  Validation 

IEEE  Standard  for  a  Software  Quality  Metrics  Methodology,  1992 
Software  Acquisition 

IEEE  Standard  for  Software  User  Documentation,  1989 

Standard  for  Developing  Software  Life  Cycle  Processes,  (approved  September  1991) 

IEEE  Standard  VHDL  Language  Reference  Manual,  1987 

IEEE  Standard  VHDL  Language  Reference  Manual  Interpretations  1992 

Standard  VHDL  Language  Reference  Manual  -  Analog  Extensions,  PAR  approved  July  1993 

Standard  VHDL  Language  Math  Package,  PAR  approved  July  1993 

Standard  VHDL  Language  Synthesis  Package,  PAR  approved  July  1993 

Standard  VHDL  Language  Timing  Methodology,  PAR  approved  July  1993 

Standard  VHDL  Language  Utility  Library,  PAR  approved  July  1993 

IEEE  Standard  Gloasary  of  Mathematics  of  Competing  Terminology,  1986 

Standard  for  Programmed  Inquiry  Learning,  or  Tracking,  1991 

IEEE  Standard  Multivalue  Logic  System  for  VHDL  Model  Interoperability,  1993 

Object  Oriented  Programming  Language  and  Environment,  Draft 
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Standard  Re/ere  oca  Model  lor  Computing  System  Tool  loiarconnectione,  1991)  [PAR  approved  for 
revision  October  1993] 

SCHEME  Language  Standard,  1990 

Uniform  Application  Program  Interface,  Graphical  User  Interface!,  Draft  3,  February  1992 
Driveability  Analysis  Data,  May  1992,  ballot  closed  17  September  1992 
Recommended  Practice  for  Evaluation  of  CASE  Tools,  1992 
Software  Maintenance  Standard,  1992 

OSI  Abstract  Data  Manipulation  API  -  Language  Independent  Specification,  1993 

X.400  Based  Electronic  Messaging  API  -  Language  Independent  Specification,  1993 

Directory  Services  Application  Programming  Interface  (API)  -  Language  Independent  Specification, 

1993 

Trial  use  Standard  for  Common  Ada  Packages  for  a  Broad  Based  Environment  for  Test  (ABBET), 
1993 

Software  Safety  Plans 

Remote  Call  Procedure  Interface  Language,  PAR  approved  May  1990,  project  moved  to  X3 
Common  OSI  Application  Program  Interfaces;  Draft  4,  August  1992,  ballot  4Q  1992 
WITHDRAWN 

Standard  for  a  Frame-based  Knowledge  Representation,  PAR  approved  July  1993 

Standard  for  an  Open  Basic  Input/output  System  Software  (OBIOS),  [PAR  approved  March  21, 1991] 

IEEE  Standard  for  Information  Technology  -  Protocols  for  Distributed  Interactive  Simulation 

Applications  -  Entity  Information  and  Interaction,  1993 

Standard  for  CD-ROM  Architectural  Profile  [PAR  Approved,  December  4. 1991] 

Standard  for  Information  Technology— Data  Access  Language  for  Full-Text  Information  Systems; 

Structured  Full-Text  Query  Language  (SFQL)  [PAR  approved  for  standard  revision,  March  19, 1992] 

Standard  for  Information  Technology — X  Window  System — Modular  Toolkit 

Standard  for  Information  Technology — X  Window  System — Open  Toolkit  Environment 

Software  Quality  Management  System,  Part  1;  Requirements,  1992 

Test  Methods  for  Measuring  Conformance  to  OSI  Abstract  Data  Manipulation  -  API,  1993 

Test  Methods  for  Measuring  Conformance  to  X.400  Based  Electronic  Messaging  Application 

Program  Interfaces  (API)  [Language  Independent],  1993 

Test  Methods  for  Directory  Services  Application  Programming  Interface  (API)  •  Language 

Independent  Specification.  1993 

OSI  Abstract  Data  Manipulation  API,  1993 

X.400  Baaed  Electronic  Messaging  C  Language  Interfaces  -  Binding  for  Applications  Program 
Interfaces  (APIs).  1993 

Directory  Services  Application  Programming  Interface  (API)  -  C  Language  Specification.  1993 
Test  Methods  for  Measuring  Conformance  to  OSI  Abstract  Dam  Manipulation  C  Language  Interfaces 
.  Binding  for  API  1993 

Test  Methods  for  Measuring  Conformance  to  X.400  Based  Electronic  Messaging  C  Language 
Interfaces  -  Binding  for  Applications  Program  Interfaces  (APIs),  1993 

Test  Methods  for  Directory  Services  Application  Programming  Interface  (API)  -  C  Language 
Specification,  1993 

’Standard  for  Information  Technology— OSI  Application  Program  Interface — ACSE  and  Presentation 
Layer  Application  Program  Interface)  Language  Independent  Specification),  PAR  approved 
July  1993 

Standard  for  Information  Technology— OSI  Application  Program  Interfaces— Test  Methods  for 
ACSE  and  Presentation  Layer  Application  Program  Interface  (language-independent  Specification), 
PAR  approved  July  1993 

Standard  for  Information  Technology— OSI  Application  Program  Interfaces — ACSE  and 
Presentation  Layer  Application  Program  Inierfaoe  (C  Language  Binding),  PAR  approved  July  1993 
Standard  for  Information  Technology — OSI  Application  Program  Interfaces — Test  Methods  for 
ACSE  and  Presentation  Layer  Application  Program  Interface  (C  Language  Binding),  PAR  approved 
July  1993 

Standard  for  Information  Technology— Signal  Processing  Applications — Processor  Graph  Method 
Software  Darign  Methodology,  PAR  ^proved  July  1993 

Guide  for  Information  Technology— Systems  Definition— Concept  of  Operation  Document,  PAR 
approved  July  1993 

POSDC,  Put  1:  System  Application  Program  Interface  (API)  [Language  Independent] 

IEEE  Standard  for  Information  Technology— Test  Methods  for  Measuring  Couforumce  to  POSDC  • 
Part  1:  System  Interfaces,  1992 

Govsromant  Network  Management  Profile  (GNMP),  NIST  National  Computer  Systems  Laboratory, 
3  June  1992 
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Military  Supplement  to  ISO  Transport  Protocol,  NIST  Natiooal  Computer  Systems  Laboratory. 
1985 


Appendix  H 


H-27 

UNCLASSIFIED 


Military  Standards 


UNCLASSIFIED 


NISTICT/SNA-85-18 

NIST  SP  500-1*2 
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Implementation  Guide  for  ISO  Traniport  Protocol,  NIST  National  Computer  Systems  Laboratory, 
1985 

Guidelines  for  the  Evaluation  of  Message  Handling  Systems  Implementations 

Government  Open  Systems  Interconnection  Users  Guide,  Version  2,  NIST,  1992 

Guidelines  for  the  Evaluation  of  File  Transfer,  Access  and  Management  Implementations.  NIST, 

1992 

Guidelines  for  die  Evaluation  of  Virtual  Terminal  Implementations,  NIST,  1995 
Stable  Implementation  Agreements  for  Open  Systems  Interconnection  Protocols,  Version  6. 
Proceedings  of  the  December  1992  NIST  OSE  Implementor's  Workshop  (OIW),  March  1993 
APP:  Application  Portability  Profile:  The  U.S.  Government's  Open  System  Environment  Profile 
OSE/1  Version  2.0,  Systems  and  Software  Technology  Division,  Computer  Systems  Laboratory. 
National  Institute  of  Standards  and  Technology,  June  1993 

Stable  Implementation  Agreements  for  Open  Systems  Interconnection  Protocols,  Version  7, 
Proceedings  of  the  December  1993  NIST  OSE  Implementor's  Workshop  (OIW),  January  1994 
(electronic  edition  is  available:  publication  is  forthcoming) 

GOSIP  Conformance  and  Interoperation  Testing  and  Registration,  Version  1,  U.S.  NIST  Systems 
and  Network  Architecture  (SNA)  Division,  December  1988 

Standards  for  the  Interchange  of  Large  Format  Hied  Raster  Documents,  U.S.  NIST,  December  1988 
Guide  on  Open  System  Environment  (OSE)  Procurements,  by  Gary  E.  Fisher,  Systems  and  Software 
Technology  Division,  Computer  Systems  Laboratory,  US  NIST,  DRAFT,  November  12,  1993, 
planned  publication  date  January  1994. 

Computer  Security  Considerations  in  Federal  Procurements 

Specifications  for  a  Secure  Hash  Standard,  NIST,  22  January  1992  (proposed  US  FIPS) 
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FIPS  9-1 
FIPS  10-3 

FIPS  11-3 
UPS  16-1 

FIPS  17-1 

FIPS  19-1 
FIPS  21-3 
FIPS  22-1 

FIPS  28 
FIPS  29-2 

FIPS  30 
FIPS  31 
FIPS  38 

FIPS  39 
FIPS  41 
FIPS  42-1 

FIPS  45 

FIPS  46-1 
FIPS  48 
FIPS  49 


Code  for  Information  Interchange,  its  Representations,  Subsets,  and  Extensions, 
14  November  1984,  (ANSI  X3.4-1977,  X3 32-1973  and  X3.41-1974] 

Representation  for  Calendar  Date  and  Ordinal  Date  for  Informatioa  Interchange,  27  January  1988. 
[ANSI  X3.30-1985(R1991)] 

Codes  for  the  Identification  of  the  States,  the  District  of  Columbia  and  the  Outlying  Areas  of  the 
United  States,  and  Associated  Areas,  28  May  1987 

Counties  and  Equivalent  Entities  of  the  United  States,  its  Possessions,  and  Associated  Areas, 
31  August  1991,  [ANSI  X3.21-1988] 

Metropolitan  Statistical  Areas  (MSAs),  31  October  1984 
Congressional  Districts  of  the  United  States,  30  November  1990 

Countries,  Dependencies.  Areas  of  Special  Sovereignty,  and  their  Principal  Administrative 
Divisions,  9  February  1984 

Guideline:  American  National  Dictionary  for  Information  Systems,  1  February  1991 

Bit  Sequencing  of  the  Code  for  Information  Interchange  in  Serial-by-Bit  Data  Transmission, 

1  September  1977,  [ANSI  X3.15-1976(R1983  A  R1990)] 

Character  Structure  and  Character  Parity  Sense  for  Serial-by-Bit  Data  Communication  in  the  Code  for 
Information  Interchange,  1  September  1977,  [ANSI  X3.16-1976(R1983  A  R1990)] 

Catalog  of  Widely  Used  Code  Sets,  7  January  1985 

COBOL,  12  January  1990,  [ANSI  X3.23-1985  and  X3  .23A-I989] 

Synchronous  Signaling  Rates  Between  Data  Terminal  and  Data  Communication  Equipment, 
1  September  1977,  [ANSI  X3.1-1976] 

Standardization  of  Data  Elements  and  Representations.  5  December  1973 

Interpretation  Procedures  for  Federal  Information  Processing  Standards  for  Software. 

14  September  1987 

Software  Summary  for  Describing  Computer  Programs  and  Automated  Data  Systems,  30  June  1974 
Guidelines  for  Automatic  Data  Processing  Physical  Security  and  Risk  Management,  June  1974 
Guidelines  for  Documentation  of  Computer  Programs  and  Automated  Data  Systems, 

15  February  1976 

Glossary  for  Computer  Systems  Security,  15  February  1976 
Computer  Security  Guidelines  for  Imptaneating  the  Privacy  Act  of  1974, 30  May  1975 
Guidelines  for  Benchmarking  ADP  Systems  in  the  Competitive  Procurement  Environment, 
15  May  1977 

Guide  for  the  Development,  Implementation  and  Maintenance  of  Standards  for  the  Representation  of 
Computer  Processed  Data  Elements,  30  September  1976 

Data  Encryption  Stand srd,  22  January  1988  (reaffirmed  until  1992),  [ANSI  X3.92-1981(R1987)) 
Guidelines  on  Evaluation  of  Techniques  for  Automated  Personal  Identification,  1  April  1977 
Guideline  on  Computer  Performance  Management:  An  Introduction,  1  May  1977 


12  Updated  September  1993. 
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FIPS  53 
FIPS  S3  DC-4 

FIPS  35-2 

FIPS  56 
FIPS  57 

FIPS5S-1 

FIPS  59 

FIPS  66 
FIPS  64 

FIPS  65 
FIPS  68-2 
FIPS  69-1 
FIPS  70-1 

FIPS  71 
FIPS  72 
FIPS  73 
FIPS  74 
FIPS  75 
FIPS  76 
FIPS  77 
FIPS  78 

FIPS  79 

FIPS  81 
FIPS  83 

FIPS  87 
FIPS  88 
FIPS  92 
FIPS  95 
FIPS  96 

FIPS  99 

FIPS  100-1 


FIPS  101 
FIPS  102 
FIPS  103 

FIPS  104-1 

FIPS  105 
FIPS  106 
FIPS  107 


FIPS  109 
FIPS  110 
FIPS  112 
FIPS  113 
FIPS  118 

FIPS  119 


Thmsmitul  form  for  Describing  Computer  Magnetic  Tape  Pile  Properties,  1  April  1978 
Guideline:  Codes  for  Named  Populated  Places,  Primary  Country  Divisions,  and  Other  Locational 
Entities  of  the  United  States  and  Outlying  Areas,  16  January  1987,  [ANSI  X3 .47-1988] 

Guideline:  Codes  for  Named  Populated  Places,  Primary  Country  Divisions,  and  Other  Locational 
Entities  of  the  United  States,  3  February  1987,  [ANSI  X3.47-1988] 

Guideline  for  Managing  Multivendor  Plug-Compatible  ADP  systems,  15  December  1978 
Guidelines  for  the  Measurement  of  Interactive  Computer  Service  Response  Time  and  Turnaround 
Time,  1  August  1978 

Representations  of  Local  Time  of  the  Day  for  Information  Interchange,  27  January  1988,  [ANSI 
X3.43-1986] 

Representations  of  Universal  lime.  Local  Time  Differentials,  and  United  States  time  Zone 
References  for  Information  Interchange,  1  February  1979,  [ANSI  X3 .51-1975] 

Standard  Industrial  Classification  (SIC)  Codes,  IS  August  1979 

Guidelines  for  Documentation  of  Computer  Programs  and  Automated  Data  Systems  for  the  Initiation 
Phase,  1  August  1979 

Guideline  for  Automatic  Data  Processing  Risk  Analysis,  1  August  1979 
Bask,  28  August  1987,  (ANSI  X3.1 13-1987] 

FORTRAN,  24  December  1985,  [ANSI  X3.9-1978(R1990) 

Representation  of  Geographic  Point  Locations  for  Information  Interchange,  14  November  1986. 
[ANSI  X3.61-1986] 

Advanced  Data  Communication  Control  Procedures  (ADCCP),  14  May  1980 

Guidelines  for  the  Measurement  of  Remote  Batch  Computer  Service,  1  May  1980 

Guidelines  for  Security  of  Computer  Applications.  30  June  1980 

Guidelines  for  Implementing  and  Using  the  NBS  Data  Encryption  Standard,  1  April  1981 

Guideline  on  Constructing  Benchmarks  for  ADP  System  Acquisitions.  18  September  1980 

Guideline  for  Planning  and  Using  a  Data  Dictionary  System,  20  August  1980 

Guideline  for  Planning  and  Management  of  Database  Applications.  1  September  1980 

Guideline  for  Implementing  Advanced  Data  Communication  Control  Procedures  (ADCCP), 

26  September  1980 

Magnetic  Tape  Labels  and  File  Structure  for  Information  Interchange,  17  October  1980,  [ANSI 
X3.27-1978] 

DES  Mode  of  Operation.  2  December  1980 

Guideline  on  User  Authentication  Techniques  for  Computer  Network  Access  Control, 
September  1980 

Guidelines  for  ADP  Contingency  Planning,  27  March  1989 

Guideline  cm  Integrity  Assurance  and  Control  in  Database  Administration,  14  August  1980 
Guideline  for  Standard  Occupational  Classification  (SOC)  Codes.  24  February  1983 
Codes  for  the  Identification  of  Federal  and  Federally-Assisted  Organizations,  23  December  1982 
Guideline  for  Developing  end  Implementing  a  Charging  System  for  Date  Processing  Services, 
6  December  1982 

Guideline:  A  Framework  for  die  Evaluation  and  Comparison  of  Software  Development  Took, 
31  March  1983 

Interfaces  Between  Data  Terminal  Equipment  (DTE)  and  Data  Chcuit-Tanirinalmg  Equipenant  (DCE) 
for  Operation  with  Packet-Switched  Data  Networks  (PSDN),  or  Between  Two  DTEs,  by  Dedicated 
Circuit,  NIST,  US  Department  of  Commerce,  20  March  1991  [ANSI  X3. 100-1989,  ITU-TS  X.25- 
1988,  ISO  7776-1986,  md  ISO  8208-1987] 

Guideline  for  Lifecycle  Validation,  Verification,  and  Testing  of  Computer  Software,  6  June  1983 
Guideline  for  Computer  Security  Certificatkm  and  Accreditation,  27  September  1983 
Codec  for  the  Identification  of  Hydrologic  Units  in  the  United  States  and  the  Caribbean  Outlying 
Areas,  15  November  1983,  [ANSI  X3.145-1986] 

ANS  Codes  for  the  Representation  of  Names  of  Countries,  Dependencies,  and  Anas  of  Special 
Sovereignty  for  Information  Interchange,  1'2  May  1986,  [ANSI  Z39.27-1984] 

Guideline  for  Software  Documentation  Management,  6  June  1984 
Guideline  on  Software  Maintenance,  IS  June  1984 

Local  Area  Networks:  Baseband  Carrier  Sense  Multiple  Access  with  Collision  Detection  Access 
Method  and  Physical  Layer  Specifications  and  Link  Layer  Protocol,  NIST,  US  Department  of 
Commerce,  31  October  1984 
Pascal,  16  January  1985 

Guideline  for  Choosing  ■  Data  Management  Approach,  11  December  1984 

Password  Usage,  30  May  1985 

Computer  Data  Authentication,  30  May  1985 

Flexible  Disk  Cartridge  Labelling  and  File  Structure  for  Information  Interchange, 
30  September  1985  (ISO  7665] 

Ada,  8  November  1985,  [ANSI/MIL-STD 1815A-1983] 
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FIPS  130-1 
FIPS  121 
FIPS  122 


FIPS  123 

FIPS  124 
FIPS  125 
FIPS  126 
FIPS  127-2 
FIPS  12S 
FIPS  132 
FIPS  133 
FIPS  134-1 
FIPS  13S 
FIPS  136 
FIPS  137 

FIPS  13S 
FIPS  139 

FIPS  140 
ms  141 

FIPS  142 
FIPS  143 

FIPS  144 

FIPS  146-1 


FIPS  147 
FIPS  148 
FIPS  149 
FIPS  130 

FIPS  131-1 
FIPS  152 

FIPS  133 
FIPS  134 

FIPS  135 

FIPS  136 
FIPS  15* 
FIPS  159 

FIPS  160 

FIPS  161 
FIPS  171 
FIPS  172 
FIPS  173 
FIPS  177 
FIPS  171 

FIPS  179 
nPSEDEFlX 

BPS  ISDN 


Graphical  Kamal  Syrian,  8  January  1991 

Videotext/Teletext  Prcaenlatioo  Level  Protocol  Syntax  (PLPS),  (ANSI  X3.U0) 

Conformance  Teats  for  FIPS  PUB  100  Version  of  1TU-TS  1980  Recommendation  X.25  Interface 
Between  Data  Terminal  Equipment  (DTE)  and  Data  C ircuit-Termin  sting  Equipment  (DCE)  for 
Operation  with  Packet-Switched  Data  Communication!  Networks,  28  May  1986 
Specification  for  a  Data  Descriptive  File  for  Information  Interchange  (DDF),  19  September  1986, 
(ANSI/ISO  8211-1985] 

Guideline  on  Functional  Specifications  for  Database  Management  Systems,  30  September  1986 

MUMPS,  4  November  1986 

Database  Language  NDL,  10  March  1987 

Database  Language  SQL,  02  February  1992,  [ANSI  X3.135-1986] 

Computer  Graphics  Metafile  (CGM),  16  March  1987,  [ANSI  X3.122-1986] 

Guideline  for  Software  Verification  and  Validation  Pirns,  19  November  1987 

Coding  sad  Modulation  Requirements  for  2400  Bit/Second  Modems,  2  June  1986 

Coding  and  Modulation  Requirements  for  4800  Bit/Second  Modems,  4  November  1988 

Coding  and  Modulation  Requirements  for  Duplex  9600  Bit/Secood  Modems,  March  1981 

Coding  and  Modulation  Requirements  for  Duplex  600  and  1200  Bit/Second  Modems,  16  June  1980 

Analog  to  Digital  Conversion  of  Voice  by  2,400  Bit/Secood  Linear  Predictive  Coding, 

28  November  1984 

Electrical  Characteristics  of  Balanced  Voltage  Digital  Interface  Circuits,  24  December  1973 
Interoperability  and  Security  Requirements  for  Use  of  the  Data  Encryption  Standard  in  the  Physical 
Layer  of  Data  Communications,  3  August  1983 

General  Security  Requirements  for  Equipment  Using  the  Data  Encryption  Standard,  14  April  1982 
Interoperability  and  Security  Requirements  for  Use  of  the  Data  Encryption  Standard  with  ITU-TS 
Group  3  Facsimile  Equipment,  4  April  1985 

Electrical  Characteristics  of  Unbalanced  Voltage  Digital  Interface  Circuits,  31  Jsnuary  1980 
General  Purpoee  37-Position  snd  9-Foci tk»  Interface  Between  Data  Terminal  Equipment  and  Data 
Circuit-Terminsling  Equipment,  10  June  1985  (Reaffirmed  1-112-89) 

Data  Communications  Systems  and  Services  User-Oriented  Performsnce  Parameters,  28  May  1985, 
[ANSI  X3.102-1983  (R1990)] 

Government  Open  Systems  Interconnection  Profile  (GOSIP),  FIPS  146-1,  Version  2.0,  U.S. 
National  Institute  of  Standards  snd  Technology,  3  April  1991  (the  1994  version  of  GOSIP  will 
point  to  the  IGOSS  specification;  publication  is  being  delayed  to  consider  recommendations  on  die 
inclusion  of  TCP/IP  and  associative  coexistence  and  convergence  issues) 

Group  3  Facsimile  Apparatus  for  Document  Transmission.  19  August  1981 
Procedures  for  Document  Facsimile  Transmission.  14  April  1982 
General  Aspects  of  Group  4  Facsimile  Apparatus,  4  November  1988 

Facsimile  Coding  Schemes  and  Coding  Control  Functions  for  Group  4  Facsimile  Apparatus. 
4  November  t988 

POSDC,  28  March  1990  [IEEE  1003.1-1988] 

Information  Processing  -  Text  and  Office  Systems  -  Standard  Generalized  Markup  language  (SGML), 
26  September  1988  [ISO  8879-1986] 

PHIGS,  14  October  1988,  [ANSI/ISO  9592.1 A3-1989  and  ANSI/ISO  9693.1*3-1990] 

High  Speed  25-Position  Interface  for  Data  Terminal  Equipment  and  Data  Circuit-Terminating 
Equipment.  4  November  1988 

Data  Communication  Systems  and  Services  User-Oriented  Performance  Measurement  Methods, 
4  November  1988,  [ANSI  X3141-1987] 

Information  Resource  Directory  System  (IRDS),  05  April  1989  [ANSI  X3. 138-1988] 

The  User  Interface  Component  of  the  Applications  Portability  Profile,  29  May  1990 

Detail  Specification  for  62.5- um  Code  Diameter/125 -urn  Cladding  Diameter  Class  LA  Multimode, 

Graded-Index  Optical  Waveguide  Fibers,  27  December  1990 

Information  Systems  -  Languages  •  Programming  Language  C,  13  March  1991  (ISO  9899:  1990; 
ANSI  X3. 159-1989) 

Electronic  Data  Interchange  (EDI),  29  March  1991 
Key  Management  Using  ANSI  X9.17,  27  April  1992 

VHSIC  Hardware  Description  Language  (VHDL),  ANSI/IEEE  1076-1987, 29  June  1992 
Spatial  Data  Transfer  Specification  (SDTS),  IS  February  1992  [DIS  10180] 

Initial  Graphics  Exchange  Specification  (KJES),  ASME/ANSI  Y14.26M-1989,  30  November  1992 
Video  Teleconferencing  Services  at  56  to  1,920  kbit/s,  ITU-TS  Series  H  Recommendations  H.221; 
230;  242;  261;  320-1990,  30  November  1992 
Government  Network  Management  Profile  (GNMP),  14  December  1992 

Specifications  for  Integration  Definition  for  Information  Modeling  (IDEF1X),  9  September  1992, 
Draft 

Integrated  Services  Digital  Network  [ITU-TS  Series  I],  planned  FIPS 
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HPS1FA  Deuapswnt  Plh  Accem  (TPA)  [IEEE  P1Q03.I],  planned  PIPS 

BOSS  The  Industry /Government  Opra  Systems  Specification  (BOSS),  Draft.  K30SS  Panel.  January  1994 

(npHtid  to  to  published  u  Version  1  in  1994;  IOOSS  U  a  joint  effort  by  Ito  US  Oowna rant.  (to 
Canadian  Government,  MAP  Uaan  Oroup,  TOT  Users  Oroup,  and  tto  Electric  Power  Reeeerrb 
Inatitnta) 


Stable  Agreements  Stable  Implementation  Agreements  for  Opan  Systems  In  tarco  noaction  Protocola,  Van  ion  2, 
Edition  1,  NIST  Special  Publication  500-16,  National  Inatitute  of  Standarda  and  Technology, 
Dacamtor  1988  (toaii  for  U.S.  OOSIP  1.0) 

Stable  Agreements  Stable  Implementation  Agreements  for  Open  Systems  Interconnection  Protocols,  Vers  km  3, 
Edition  1,  NIST  Special  Publication  300-177,  National  Institute  of  Standards  and  Technology, 
March  1990  (Proceedings  of  December  1989  NIST  OSI  Implementor’s  Workshop;  basis  for  U.S. 
OOSIP  2.0) 

Working  Agreements  Working  Implementation  Agreements  for  Open  Systems  Interconnection  Protocols:  Continuing 
Agreements,  Volume  2,  Number  2,  NISTIR  90-4247,  National  Inatitute  of  Standarda  and 
Technology,  February  1990  (Proceedings  of  December  1989  NIST  OSI  Implementor's  Workshop) 


Yellow  Book  Computer  Security  Requirements -Guidance  for  Applying  the  Department  of  Defense  Trusted 

Computer  System  Evaluation  Criteria  in  Specific  Environments  (Yellow  Book),  CSC -STD-003-85, 
DoD  Computer  Security  Center,  June  1983 

Yellow  Book  Rationale  Technical  Rationale  Behind  CSC -STD-003 -8 5:  Computer  Security  Requirements-Goidencs  for 
Applying  foe  Department  of  Defense  Trusted  Computer  System  Evaluation  Criteria  in  Specific 
Environments,  CSC -STD-004-85,  DoD  Computer  Security  Carter,  June  1913 
Orange  Book  Department  of  Defense  Trusted  Computer  System  Evaluation  Criteria  (Orange  Book), 

DoD  5200.28-STD,  DoD  Computer  Security  Center.  December  1983 
Red  Book  Trusted  Network  Interpretation  (Red  Book),  NCSG-TC-005,  Version  1.  National  Computer  Security 

Center,  July  1987 


SDN301 
SDN.  401 
SDN.601 

SDN. 701 

SDN.702 

SDN.801 
SDN. 802 
SDN. 802/1 


SMI  902 

SDN  903 

SDN  906 


Secure  Date  Network  System  (SDNS)  Security  Protocol  3  (SP3),  Revision  1.5,  SDNS  Protocol  and 
Signalling  Working  Group,  13  May  1989,  National  Security  Agency,  UNCLASSIFIED 
Secure  Date  Network  Syatem  (SDNS)  Security  Protocol  4  (SP4),  Revision  13,  SDNS  Protocol  and 
Signalling  Working  Group,  2  May  1989,  National  Security  Agency,  UNCLASSIFIED 
Secure  Date  Network  System  (SIMS)  Key  Management  Profile,  Communication  Protocol 
Requirements  for  Support  of  foe  SDNS  Key  Management  Protocol.  Revision  13,  SDNS  Protocol 
and  Signalling  Working  Group,  11  August  1989,  National  Security  Agency.  UNCLASSIFIED 
Secure  Date  Network  System  (SDNS)  Message  Security  Protocol  (MSP),  Revision  13,  SDNS 
Protocol  and  Signalling  Working  Group,  1  August  1989.  National  Security  Agency, 
UNCLASSIFIED 

Secure  Date  Network  System  (SDNS)  Directory  Specifications  for  Utilization  with  the  SDNS 
Message  Security  Protocol  (MSP),  Revision  1.4,  SDNS  Protocol  and  Signalling  Working  Group, 
1  August  1989,  National  Security  Agency,  UNCLASSIFIED 

Secure  Date  Network  System  (SDNS)  Access  Control  Concept  Document,  Revision  13,  SDNS 
Protocol  and  Signalling  Working  Group,  26  July  1989,  National  Security  Agency.  UNCLASSIFIED 
Secure  Date  Network  System  (SDNS)  Access  Control  Specification,  Revision  IB,  SDNS  Protocol 
and  Signalling  Working  Group,  23  July  1989,  Natiooal  Security  Agency,  UNCLASSIFIED 
Secure  Date  Network  System  (SDNS)  Access  Control  Specification.  Addendum  1.  Access  Control 
Information  Specification  (ACIS),  Revision  1.0,  SDNS  Protocol  and  Signalling  Working  Group. 
23  July  1989,  Natiooal  Security  Agency,  UNCLASSIFIED 

Secure  Date  Network  System  (SDNS)  Key  Management  Protocol,  Definition  of  Services  Provided  by 
foe  Key  Management  Application  Service  Element  (KMASE),  Revision  33,  SDNS  Protocol  and 
Signalling  Working  Group,  1  August  1989,  National  Security  Agency,  UNCLASSIFIED 
Secure  Date  Network  System  (SDNS)  Key  Management  Protocol,  Specification  of  the  Protocol  for 
Services  Provided  by  foe  Key  Management  Application  Service  Element  (KMASE),  Revision  3.2, 
SDNS  Protocol  and  Signalling  Working  Group,  1  August  1989,  National  Security  Agency, 
UNCLASSIFIED 

Secure  Date  Network  System  (SDNS)  Key  Management  Protocol,  SDNS  Traffic  Key  Attribute 
Negotiation,  Revision  13b,  SDNS  Protocol  and  Signalling  Working  Group,  18  September  1989, 
National  Security  Agency,  UNCLASSIFIED 
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STANDARDS  FOR  PROFILES  IDENTIFIED  IN  THE  NOSIP  STRATEGY 

1 .  INTRODUCTION 

Tbe  NATO  Open  Systems  Interconnection  Profile  (NOSIP)  Strategy  [Ref.  NATO  1993}  bat  been  developed 
by  die  Tri-Service  Group  on  Communications  and  Electronics  (TSGCE)  and  is  expected  to  be  promulgated  in  1994 
by  the  Conference  of  National  Armaments  Directors  (CNAD).  The  NOSIP  Strategy  is  an  outgrowth  of  the  N77S 
Transition  Strategy  (Sixth  Edition)  [Ref.  NATO  1991].  This  appendix  identifies  tbe  stacks  of  base  standards 
specified  in  the  NOSIP  Strategy  for  example  application,  transport,  and  relay  profiles.  All  are  based  on  or 

emerging  recommendations  [e.g.,  International  Standard  Profiles  (ISPs)]  developed  by  international  or  regional 
standards  bodies. 

The  notation  nsed  to  identify  and  distinguish  tbe  functional  profiles  is  that  specified  in  ISCVIEC  TR 10000. 
This  taxonomy  is  described  in  Section  16.1.2. 

2.  APPLICATION  PROFILES 

2.1  Four  file  management  functional  profiles  are  shown  in  Figure  1-1,  all  from  ISP  10607: 

60  AFT11,  Simple  File  Transfer 
<b)  AFT12,  Positional  File  Transfer 
(c)  AFT22,  Positional  File  Access 
60  AFT3,  FT  AM  Hie  Management 


(a)  AFT11.  Simple  Fla  Transfer  (b)  AFT1 2,  PoaMonal  FHa  Transfer 


Figure  M.  File  Management  Application  Profiles 

22  There  are  two  Military  Message  Handling  System  (MMHS)  applicatioo  profiles  identified  in 
NOSIP  Strategy,  both  derived  from  emerging  STANAGs  being  developed  by  TSGCE  Subgroup  9: 

60  AMHlx(M),  MMHS  Common  Facilities,  Table  1-1 

(b)  AMH9x(M),  MMHS  Military  Messaging.  Table  1-2  (the  stacks  are  common  to  AMHlx(M). 


! _ AFT3 _ 1 

Application  Laysr 

ISO  8571, 

ISO  8640.  ISO  8660 

Prsssntation  Laysr 

ISO  8822,  ISO  8823 

ISO  8824.  ISO  8826 

Ssssion  Laysr 

ISO  8328,  ISO  8327 

(d)  AFT3,  FTAM  Fla  Management 


1  AFT22  1 

Appfcatfon  Laysr 

ISO  8571, 

ISO  8848,  ISO  8850 

Prsssntation  Laysr 

ISO  8822,  ISO  8823 

ISO  8824,  ISO  8825 

Ssssion  Laysr 

ISO  8326,  ISO  8327 

(c)  AFT22,  Positional  FIs  Accsss 


1  aftii  [ 

Appfcatkm  Laysr 

ISO  8671, 

ISO  8648,  ISO  8650 

Prsssntation  Laysr 

ISO  8822,  ISO  8823 

ISO  8824,  ISO  8825 

Ssssion  Laysr 

ISO  8326,  ISO  8327 

1  AFT12  1 

Application  Laysr 

ISO  8571, 

ISO  8648,  ISO  8660 

Prsssntation  Laysr 

ISO  8822,  ISO  8823 

ISO  8824,  ISO  8825 

Ssssion  Laysr 

ISO  8326,  ISO  8327 

Appendix  I 


1-1 

UNCLASSIFIED 


Standards  for  Example  Profiles 


UNCLASSIFIED 


TaMa  1-1 .  AMH1x(M),  MMH8  Common  Faellitios 


Laysr 

— imnTflfi — 

aMh12(M) 

P  AllHl3(lJ} 

7 

Craft  §TAna6  4404 

Draft  STANAG  4404  "l 
ISO  9072-2 

Draft  STANAG  4404 

ISO  9066-2 

ISO  9066-2 

ISO  9066-2 

ISO  8660 

ISO  8650 

ISO  8650 

e 

Draft  STANAG  4266  ”1 
(ISO  8823) 

Draft  STANAQ  4259 
(ISO  8825) 

Draft  STANAG  4258 
(ISO  8824) 

Draft  STANAG  4266 
(ISO  8823) 

Draft  STANAG  4259 
(ISO  8825) 

Draft  STANAG  4258 
(ISO  8824) 

Craft  SsTANAG  4266 
(ISO  8823) 

Draft  STANAG  4259 
(ISO  8825) 

Draft  STANAG  4258 
(ISO  8824) 

5 

braft  StANAG  4265 
(ISO  8237) 

Draft  STANAG  4265 
(ISO  8237) 

Draft  STANAG  4265  | 

(ISO  8237) 

Tablo  1-2.  AMH9x(M),  MMHS  Military  Massaging 


Laysr 

- AMhsi(U] - 

AMH92(M) 

- CTBSiflgy - 

7 

Draft  STANA6  4406 

Draft  STANAG  4406 

ISO  9072-2 

Draft  STANAG  4406 

ISO  9066-2 

ISO  9066-2 

ISO  9066-2 

ISO  8660 

ISO  8650 

ISO  8650 

6 

Draft  &TANAb  4266  H 
(ISO  8823) 

Draft  STANAG  4259 
(ISO  8825) 

Draft  STANAG  4258 
(ISO  8824) 

Draft  StANAG  4266 
(ISO  8823) 

Draft  STANAG  4259 
(ISO  8825) 

Draft  STANAG  4258 
(ISO  8824) 

Craft  §TANAG  4266 
(ISO  8823) 

Draft  STANAG  4250 
(ISO  8825) 

Draft  STANAG  4258 
(ISO  8824) 

5 

Draft  STANAG  4266 
(ISO  8827) 

Draft  STANAG  4265 
(ISO  8827) 

Craft  STANAG  4266 
(ISO  8827) 

2.3  Table  1-3  identifies  tbe  stacks  of  standards  for  three  system  management  profiles: 

(a)  A0M211,  General  Mnagemem  Capability 

(b)  AOM221,  General  Event  Repot  Control 

(c)  AOM231,  General  Log  Control. 


TaMs  1-3.  AMH9x(M),  MMHS  Military  Massaging 


A6U211 

AOM221 

AOM231 

7 

IS0 10164-1 

IS0 10164-1 

IS0 10164-1  “™” | 

IS0 10164-2 

IS0 10164-2 

IS0 10164-2 

IS0 10164-3, 10164-4 

ISO  10164-5 

IS0 10164-6 

IS0 10166-2 

IS0 10165-2 

IS0 10165-2 

ISO  9595 

ISO  9595  1 

ISO  9596-1 

ISO  9596-1 

ISO  9596-1 

ISO  9072-1. 9072-2 

ISO  9072-1, 9072-2 

ISO  9072-1, 9072-2 

1808649.8660 

ISO  8649,  8650 

ISO  8649,  8650 

IS0 11183-1 

ISO  11183-1 

IS0 11183-1 

IS0 11183-2 

ISO  11183-2 

IS0 11183-2 

6 

IF'-T.j  r  i'i  —  ramaai 

ISO  8822, 8823 

1808824.8825 

ISO  8824, 8825 

ISO  8824, 8826 

IS0 1183-1 

ISO  1163-1 

IS0 1183-1 

ISO  8326, 8327 

ISO  8326, 8327 

l£o  8326,  8327 

I  1 

ISO  B326/AD2, 8327/AD2 

ISO  8326/AD2, 8327/AD2 

ISO  8326/AD2, 8327/AD2 

■ 

ISP  11183-1 

ISP  11183-1 

ISP  11183-1 
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3.  TRANSPORT  PROFILES 

Figure  1-2  identifies  1 1  transport  profiles.  T-profiies  use  tbe  connection -oriented  transport  service  (COTS): 
TA  involves  tbe  use  of  the  connectionless  network  service  (CLNS);  TB,  TC,  and  TD  all  involve  tbe  connection- 
oriented  network  service  (CONS)  and  differ  as  to  tbe  required  classes  (TPO,  TP2,  TP4)  of  tbe  COTS.  [U-profiles  (no 
examples  given)  use  tbe  connectionless  mode  transport  service  (CLTS)].  These  transport  profiles  are: 

(a)  TA1  lxl.  Permanent  Access  to  a  PSDN  over  a  PSTN  or  a  CSDN,  Virtual  Call  (source:  ISP  10608-5) 

(b)  TA51(M),  COTS  over  CLNS  in  a  LAN  with  CSMA/CD  (military  variant;  sources:  ISP  10606-2, 
STANAGs  4408-1, 4408-2, 4406-3) 

(c)  TA53,  COTS  over  CLNS  in  Token  Ring  LAN  with  LLC1  (source  ISP  10608-4) 

(d)  TA54(M),  COTS  over  CLNS  in  FDDI  LAN  (military  variant;  sources  ISP  10608-14,  STANAGs 
4408-1. 4406-2, 4408-3) 

(e)  TCllxl(M),  COTS  over  CONS,  Permanent  Access  to  a  PSDN  via  PSTN  Leased  Line  [TC1111(M)] 
or  Digital  Data  Circuit  (TCI  121(M)]  (military  variant;  sources:  STANAGs  4409-1, 4409-2, 4409-3) 

(f)  TC1231,  ISDN  B -Channel,  Virtual  Call,  Switched  Access  to  a  PSDN  (sources:  ISP  10609-2, 10609- 
31) 

(g)  TC41 1 1,  ISDN  B-Channel  Semi-permanent  Service,  X.25  DTE  to  DTE  (COTS  and  CONS)  (sources: 
ISP  10609-2, 10609-32) 

<h)  TC42U,  ISDN  B -Channel  Circuit-mode  Service,  X.25  DTE  to  DTE  (COTS  and  CONS)  (sources: 
ISP  10609-2, 10609-33) 

fi)  TC43111,  ISDN  D-Channel,  Virtual  Call,  Packet-mode  Service,  Without  X.931  (sources: 
ISP  10609-2, 10609-34)  (see  note  below) 

(j)  TC43112,  ISDN  D-Channel,  Virtual  Call,  Packet-mode  Service,  With  X.931  (sources:  ISP  10609-2, 

10609-35) 

Or)  TC4331,  ISDN  B -Channel,  Demand  Access  Virtual  Call,  Packet-mode  Service  (sources:  ISP  10609- 
2, 10609-38). 

The  ISDN  profile  in  Figure  1-2  (i)  requires  further  study.  The  need  for  an  ISDN-specific  convergence- 
function  sublayer,  such  as  the  one  specified  in  ISO  9574  in  profile  TC  43111,  requires  further  study  because  of  the 
presence  of  a  nailed-up  virtual  circuit. 


r  TAIIxl  1 

4 

Transport  Layer 

ISO  8073 

ISO  8073/AD2 

3 

Network  layer 

ISO  8208 

ISO  8473 

2 

Data  Link  Layer 

ISO  7778 

1 

Physical  Layer 

CCTTDC21 

ccnrx2twa 

Reference:  ISP  10608-5. 

(a)  TAIIxl,  Permanent  Access  to  a  PSDN  over 
a  PSTN  ora  CSDN,  Virtual  Cal 


Figure  1-2.  Transport  Functional  Profiles 
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1 _ TASKM) _ 1 

Transport 

Laver 

STANAG  4264,  Annax  E 

DIS  8073 

TAnnrm(M) 

Group 

Profile: 

Parti 

fct-j - «- 

FMCWOrK 

Layar 

STANAG  4263,  Annax  B 

Tniatad  Communications  Sublayer  fTCS) 

STANAG  4263,  Annax  fz 

ISO  8473  Subnetwork  Indapandant 

Recurs  monts 

STANAG  4263,  Annax  E 

ISO  8473  with  ISO  8802 

Subnetwork  Dependant  Convergence 
Function  (SNOCR  and  ISO  9542 

TAnnnn(M) 

Profile: 

Part  2, 
TA5n(M) 

Data  Link 
Layar 

STANAG  4262,  Annex  fc 

ISO  8802-2  (LLC) 

STANAG  4262,  Annax  E 

ISO  8802-3  (MAC) 

TAnnnn(M) 

Profile: 

Parts, 

_ TASlftl) 

Physical 

Layar 

STANAG  4261 

ISO  8802-3  (LPs.  AUI.  MAU) 

References:  ISP  10608-2;  STANAGs  4408-1. 4408-2, 4406-3. 


(b)  TA51(M),  COTS  over  CLNS  in  a  LAN  wth  CSMA/CD  (Miltary  Variant) 


1  TA53  1 

4 

Transport  Layer 

ISO  8073 

ISO  8073/ AD  2 

3 

Network  Layer 

ISO  8473 

ISO  9542 

2 

Data  Link  Layer 

ISO  8802-2  Type  1 

ISO  8802-5  (MAC) 

1 

Physical  Layer 

ISO  8802-5  (PHY) 

Reference:  ISP  10608-4. 

(c)  TA53,  COTS  over  CLNS  in  Token  Ring  LAN  with  LLC1 


1 _ TAS4M _ 

Transport 

Layer 

STANAG  4264,  Annex  E 

DIS8073 

TAnrmn  (M) 
Group 
Pronie: 

Parti 

NflmXK 

Layer 

STANAG  4263,  Annex  B 

Trusted  Communications  Sublayer  (TCS) 

STANAG  4263,  Annax  E 

ISO  6473  Subnetwork  independent 

Reautroments 

STANAG  4263,  Annex  E 

ISO  8473  with  ISO  8802 

Subnetwork  Dependent  Convergence 

Function  (SNDCF)  and  ISO  9542 

TAnrmn  (M) 
Profile: 

Part  2, 
TAGn(M) 

Data  Link 
Layar 

STANAG  4262,  Annex  E 

ISO  8802-2  (LLC) 

STANAG  4262,  Annex  E 

ISO  8802-3  (MAC) 

ANSI  X3T9.5 
FDOISMT 

TAnrmn  (M) 
Profile: 

Part  4. 
TA54(M) 

Physical 

Layer 

STANAG  4281 

ISO  9314-1  (PHY) 

STANAG  4261 

ISO  9314-3  (PMD) 

References:  ISP  10808-14,  STANAGa  4408-1, 4408-2, 4408-3. 


(d)  TA54(M),  COTS  war  CLNS  in  FDD!  LAN  (MHtary  Variant) 


Figure  1-2.  Transport  Functional  Profllaa  (Cont'd) 
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Transport 

Laver 

ANAG  4264,  Annex  E 

ISO  8073 

Network 

Layer 

STAN  AG  4263,  Annex  B;  Trusted 
Communications  Sublayer  (TCS) 

STANAG  4263,  Annexe 

ISO  8878 

(Subnetwork-type  Independent 
requirements) 

STANAG  4263,  Annexe 

ISO  8878,  ISO  8208 
(Subnetwork-type  dependent 
requirements) 

Data  Link 
Laver 

STANAG  4262,  Annex  D 

ISO  7776 

Physical 

Laver 

STANAG  4261  '  ” 

CCJTTX^I.CCrrTXilbis 

TCnmn(M) 

Group 

Profit* 


XXI 111  (M)/ 
XX1 121  (M) 
Profile 


TC1111/M)/ 
TC1 121  (M) 
Profle 


(•)  TCI  1x1  (M),  COTS  over  CONS,  Permanent  Access  to  a  PSDN  via  PSTN  Leased  Una 
(TC11 1 1(M)J  or  Digital  Data  Circuit  [TC1 121  (M)] 


1  -  - 1 

C1231 

4 

iti  '""iirTrsH 

ISO  8073  {Classes  0  and  2) 

3 

Network 

Layer 

m3 

ISO  9574 

3b 

CCfTT  Q.931 

3a 

ISO  8208 
(X.25PLP) 

2 

Data  Link  Layer 

>  CCITTQ.921 

fLAPD) 

wm* 

1 

wmmm&i  i  ietimh  i 

D-Chamel  B-Channei 

(control  plane)  (ueer  plane) 


Referencee:  ISP  10609-2. 10609-31. 

(f)  TC1231 .  ISDN  B-Channei,  Virtual  Cal,  Switched  Accese  to  a  PSDN 


»  Tddiii  i 

4 

Transport  Layer 

ISO  8073  (Classes  0  and  2) 

3 

Network  Layer 

ISO  8208 

ISO  8878 

2 

Data  Link  Layer 

ISO  7778 

1 _ 

Physical  Laver 

1.430  /  1.431 

B-Channel 


Referencee:  ISPe  10609-2, 10609-32. 

(g)  TC41 11,  ISDN  B-Channel  Semipermanent 
Service.  X2S  DTE  to  DTE  (COTS  and  CONS) 

Figure  1-2.  Transport  Functional  Profilea  (Cont’d) 
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>wm'  ipigpiiipppppif «pp  .4,' 

UNCLASSIFIED 


ill'  V1' -Tv'il*", 7'  A— 1 

m  :.r  v^T^.  — ttv: 

3 

NVtwOfX 

Layer 

E3 

—  l  1  I  HIM 

3b 

CCrrTQ.931 

3a 

2 

■»//;■ 

1 

l«  '1  11  1*  '1 

CCrTT  1.430  /  1.431  1 

^Channel  ^Channel 

(control  plana)  (war  plana) 


References:  ISP  10609-2. 10609-33. 

9i)  TC4211,  ISON  B-Channai,  Circuit-mode  Service, 
X2S  DTE  to  DTE  (COTS  and  CONS) 


TC43111 


ISO  8073  (Claaaaa  0  and  21 


Network  Layer 


I  See  text  I 
ISO  8878 


Data  Link  Layer 


CCnf  Q.B21 


(LAP  D) 

66ffTtl.43o  1 1, 
D-Channel 


431 


(control  plane)  (user  plane) 
Raferencea:  ISP  10600-2, 10609-34. 

(I)  TC43111,  ISON  D-Channel,  Virtual  Cal  Packet-mode  Service, 
Without  X.931 


4 

3 

Network  Layer 

mn 

1  ISO  9574  | 

EH 

ccm  Q.931 

1  ISO  8878  0 

£ 

2 

OCfTT  0.921 

_ &AP21 _ 

1 

(control  plane)  (war  plane) 

References:  ISP  10609-2, 10609-34. 


9)  TC431 11,  ISON  D-ChanneL  Virtual  Cal  Packet-mode  Service, 
With  X.931 


4 

Hi'V  V-riirTTTMHWl 

EH 

ISO  8878  i 

3 

Network  Layer 

3b 

l^ifl 

3c 

■rr^l 

■a 

ill  T  --Msm 

L-L- 

CCTrT  1.430  /  1.431  j 

D-Channel  B-Channel 


Raferencea:  ISP  10609-2, 10809-38. 

(I)  TC4331,  ISON  B-CharmoL  Demand  Aoceae  Wtuai  Cal, 
Packet-mode  Service 

Figure  1-2.  Transport  Functional  Profiles  (Cont’d) 


A - if—  V 

Appendix  1 


1-6 

UNCLASSIFIED 


Standards  for  Example  Profiles 


UNCLASSIFIED 


4.  RELAY  PROFILES 

Figure  1-3  identifies  two  relay  profiles.  These  arc: 

00  RASl.llxl,  Relaying  the  CLNS,  CSMA/CD  LAN  to  PSDN  Virtual  Call 

(b)  RA51.51,  Relaying  the  CLNS,  CSMA/CD  LAN  to  CSMA/CD  LAN 

(c)  RASl.llxl,  Relaying  the  X25  Packet  Layer  Protocol.  CSMA/CD  LAN  to  PSDN  Virtual  Call 

<b)  RD51.51,  Relaying  the  MAC  Service  Using  Transport  Bridging,  CSMA/CD  LAN  to  CSMA/CD 
LAN. 


f  RASl.llxl  | 

Network  Layer 

ISO  8473,  ISO  9542  j 

ISO  8208 

Data  Link  Layer 

ISO  8802-2  Type  1 

ISO  8802-3  (MAC) 

ISO  7778 

Physical  Layer 

ISO  8802-3  (PHY) 

CCfTTX21, 
X21bia.  V-Series 

Aaference:  SISK  10613-8, 106134. 


(a)  RA51 .11x1,  Relaying  the  CLNS,  CSMA/CD  LAN  to  PSDN  Virtual  Cal 


|  RAS1.51  | 

Network  Layer 

ISO  8473 

ISO  9542 

Data  Link  Layer 

ISO  8802-2  Type  1 

ISO  8802-3  (MAC) 

Physical  Layer 

ISO  8802-3  (PHY) 

ISO  8802-3  (PHY) 

Reference:  DISP 10813-5. 


(b)  RA51. 51,  Relaying  the  CLNS,  CSMA/CD  LAN  to  CSMA/CD  LAN 


[  RC51.1 1x1  j 

Network  Layer 

ISO  8208 

ISO  8881 

ISO  TR 10029 

ISO  8208 

Date  Link  Layer 

ISO  8802-2  type  2 

ISO  8802-3  (MAC) 

ISO  7778 

Physical  Layer 

ISO  8802-3  (PHY) 

ccrrrxii 

X21bie,  V  eeriee 

Reference:  ISPa  IOC  13-5, 10513-8. 


(c)  RC51.11x1,  Relaying  the  X2S  Packet  Layer  Protocol, 
CSMA/CD  LAN  to  PSDN  Virtual  Cel 

Figure  14.  Relay  Functional  Profllaa 
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I  R061.S1  | 

Data  Link  Layer 
(MAC  Sublayer) 

ISO  8802*3  (MAC) 

IS0 10038 

ISO  8802-3  (MAC) 

Physical  Layer 

ISO  8802*3  (PHY) 

ISO  8802-3  (PHY) 

Reference:  ISP  10612-4. 

(d)  RD51.51,  Relaying  the  MAC  Service  Using  Transport  Bridging, 
CSMA/CD  LAN  to  CSMA/CD  LAN 


Figure  1-3.  Relay  Functional  Profllaa  (Cont’d) 
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MILITARY  ENHANCEMENTS  FOUND  IN  OSI  STANAGS 
1 .  STATUS  OF  NATO  OSI  STANAGS 

Table  J-1  identifies  the  STANAGs  being  developed  that  will  specify  ISO  tiaodards  and  applicable  military 
options  and  extensions,  if  any.  Woik  has  begun  on  all  these  STANAGs,  hot  only  the  NATO  Reference  Model, 
STANAG  4250.  has  been  ratified.  Originally,  TSGCE  SG9  planned  to  issue  a  single  STAN  AG  for  all  services  aid 
a  second  STANAG  for  all  protocols  at  each  layer,  giving  a  total  of  14  STANAGs  in  to  STANAG  4250,  the 

NATO  Reference  Model,  hi  October  1987,  TSGCE  SG9  agreed  [Ref.  UK  1988,  Annex  1.2]  to  work  a  the 
Application  Layer  for  single  STANAGs  for  each  Application  Layer  service,  such  as  MMHS  (STANAG  4406). 
Protocol  specifications  as  well  as  service  definitions  would  be  addressed  in  that  STANAG. 

Little  progress  on  the  lower  layer  STANAGs  has  been  made  during  the  past  two  years.  Most  of  the 
changes  observed  on  the  various  drafts  of  these  doemnents  during  this  period  have  been  editorial.  In  a  few  cases, 
same  PICS  proformas  have  been  added.  Since  these  documents,  for  the  most  part,  adopt  international  standards 
without  enhancements,  it  is  not  dear  why  these  standards  were  not  ideated  for  ratification  in  1991.  The  need  for  the 
layer  STANAGs  is  not  clear,  especially  if  their  primary  role  is  to  provide  cover  sheets  far  international  civil 


Tabln  J-1.  NATO  081  Standards 


Relation 

Service  Definitions 

Protocol  Specifications  j 

to  OSI 

STANAG 

Statue 

Doe.  Data 

STANAG 

Status 

Doc.  Date 

4250,4250-1 

Ratified 

21  August  1990 

N/A 

- 

4250-2 

Staffing 

Decanter  1993 

N/A 

Reference 

4250-3 

Draft 

21  March  1993 

N/A 

Modal 

4250-4 

Draft 

26  Apr!  1993 

N/A 

4250-5X 

Cancalad 

1992 

N/A 

4250-OX 

Canceled 

1992 

N/A 

4250-5Y 

Cancalad 

October  1993 

N/A 

Layer  1 

ehh 

Staffing 

1  1  II  — 

17  March  1993 

Layer  2 

14252 

Staffing 

26  March  1993 

18  March  1993 

BHU 

Draft 

19  March  1993 

4263 

Draft 

19  March  1993 

4254 

Staffing 

19  Match  1993 

4264 

19  March  1993 

■rm 

4255 

Ratified 

8'^'A 1  VI* 

4265 

Ratified 

m-'V.  mi1  VAh-y 

4256 

Ratified 

22  January  1993 

4266 

Ratified 

22  January  1993 

Layer  6 

4258  (ASN.1) 

Ratified 

22  January  1993 

4259  (ASN.1 
BER) 

Ratified 

22  January  1993 

4257 

Staffing 

November  1993 

November  1993 

m ursm 

EZICHISM 

Draft 

November  1993 

N/A 

Profile 

Draft 

15  May  1993 

N/A 

Profile 

nzmmm 

Draft 

N/A 

mm i 

Draft 

7  April  1993 

N/A 

-SM- 

ItOVNO 

14410 

Draft 

7  April  993 

N/A 

Profile 

14413 

Draft 

January  1993 

N/A 

Note:  Staffing  meant  that  a  final  draft  haa  been  aubmitted  by  Subgroup  9  to  the  NATO  International  Mfttary  Staff  for 
translation  and  dtetribution  to  tha  nations  tor  ratification. 

Source:  [Rannaatad  1904). 
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2.  PHYSICAL  LAYER  STANAGS 

The  two  STANAGs  (4251  and  4261)  characterize  all  but  three  of  the  areas  identified  as  ‘not  envisioned  to 
affect  the  Physical  Layer.”  The  areas  in  which  enhancements  are  possible  (network/systems  managwnwit  security, 
robustness,  and  quality  of  service)  are  marked  "military  enhancements  are  for  further  study."  STANAG  4261  notes 
that  mechanical  aspects  require  militarization  but  that  specifications  are  for  further  study.  STANAG  4261  provides 
NATO  PICS  proformas  for  ISO  21 10,  ISO  4903,  and  ISO  88023;  details  for  ISO  88023  are  left  for  further  study. 
In  addition,  STANAG  4261  provides  NATO  PICS  proformas  far  the  following  ITU-TS  standards;  V3,  Vri,  V.710, 
V.ll,  V38,  and  X.1  (Annex  I  states  that  a  proforma  for  V34  is  provided  but  there  is  no  proforma  appendix  for  this 
standard). 

3.  DATA  LINK  LAYER  STANAGS 

STANAG  4252  will  address,  as  does  ISO  8886  upon  which  it  is  based,  both  CO  and  CL  modes  of  service. 
Both  draft  (March  1993)  STANAGs  4252  and  4262  identify  deficiencies  only  in  one  area  (management)  for  which  no 
enhancements  are  identified;  any  enhancements  would  depend  on  ongoing  work  in  ISO. 

4.  NETWORK  LAYER  STANAGS 

STANAG  4253  (April  1993)  is  based  on  ISO  8348  ( Network  Service  Definition),  including  the  three 
addenda,  and  thus  provides  for  both  connection-mode  and  connectionless  data  transmission.  The  Security  Annex  is 
classified;  as  provided  in  the  NOSA  document  (see  Section  8.13.2),  it  addresses  services  such  as  peer  entity 
authentication,  data  origin  authentication,  access  control,  connection  confidentiality,  connectionless  confidentiality, 
traffic  flow  confidentiality,  connection  integrity  without  recovery,  and  connectionless  integrity.  STANAG  4253 
addresses  the  areas  of  deficiencies  of  the  civil  standards  shown  in  Table  J-2  for  providing  military  feature 

wihanoHwnw 

Annex  D  to  STANAG  4253  discusses  the  two  types  of  addresses  used  in  the  Network  Layer  (1) 
subnetwork  address,  which  identifies  a  point  of  attachment  to  a  subnetwork  (e.g„  an  X.25  network)  and  (2)  network 
address.  The  subnetwork  address  must  be  derivable  from  the  network  address,  either  directly  using  a  field  of  the 
network  address  or  indirectly  using  routing  table  or  directory  service.  Annex  D  provides  technical  detail  on  network 
address  syntax,  structure  of  an  network  service  access  point  address,  NATO  initial  domain  identifier  format,  and 
NATO  address  allocation  scheme. 

STANAG  4263  (April  1993)  specifies  provision  erf  the  OSI  network  service  using  the  X.25  Packet  Layer 
Protocol  (PLP);  application  of  X.75;  and  provision  of  connectionless  service  using  ISO  8473.  Use  of  X.25  PLP 
over  an  ISO  8802  LAN  is  not  addressed. 

The  required  military  enhancements  for  providing  CONS  using  the  X.25  PLP  (Annex  Q  are  given  in 
Table  J-3.  Appendix  1  to  Annex  C  is  the  PICS  proforma.  Appendix  2  to  Annex  C  provides  a  set  of  enhancements 
to  X.25  for  additional  optional  user  facilities  to  meet  military  requirements  for  security,  precedence,  and  preemption. 
They  include  (1)  "default  security  level  assignment  (an  optional  user  facility  agreed  for  a  period  of  time)  to  provide 
for  the  selection  of  default  security  level — the  highest  security  level  that  may  be  associated  with  any  virtual  call  at 
the  DTE/DCE  interface — from  the  list  of  security  levels  supported  by  the  network  provided”;  (2)  ‘security  level 
selection  and  indication’  that  may  be  requested  by  a  DTE  for  a  given  virtual  call;  (3)  ‘default  priority  levels 
assignment";  and  (4)  "priority  level  selection  and  indication." 

An  enhancement  for  only  one  military  feature  (precedence  and  preemption)  is  specified  in  Annex  D  for 
interconnecting  two  packet-switched  networks  using  CONS  and  the  X.75  PUP.  Procedures  and  formats  for  the 
enhancement  are  specified  in  Appendix  2  to  Annex  D.  The  enhancement  includes  introduction  of  two  optional 
network  utilities  to  augment  the  standard  network  utilities:  security  level  selection  and  priority  level  selection. 

Annex  E  to  STANAG  4263  [Connectionless  Network  Protocol  ( CLNP )]  derates  an  internet  protocol  (IP) 
providing  the  CLNS.  The  CLNP  relies  on  the  provision  of  an  underlying  CL-mode  service  by  real  subnetworks  or 
data  links.  It  is  classified  as  a  subnetwork-independent  convergence  protocol.  The  underlying  CLNS  may  be 
obtained  either  directly  from  a  CL-mode  real  subnetwork  or  indirectly  through  the  operation  of  an  appropriate 
subnetwork-dependent  convergence  function  (SNDCF)  or  protocol  (SNDCP)  over  a  CL-mode  real  subnetwork. 
Annex  E  is  based  on  ISO  8473  (Sections  3-9  and  Annexes  A-C)  and  provides  extensions  for  die  following  three 
military  features: 

*  Security.  A  security  parameter  can  be  provided  in  every  CLNP  protocol  data  unit  (PDU)  using  the 
Security  Option.  This  is  described  in  Appendix  3  to  Annex  E. 

•  PredvWmce  md  preemption  Priority  is  realized  through  selection  of  a  priority  parameter  in  the 
options  port  of  the  PDU  header.  Use  of  the  priority  parameter  is  optional.  When  implemented  for  use 
within  aid  systems  and  intermediate  systems,  the  priority  parameter  may  be  used  as  a  criterion  for 
preempting  memory  and/or  processing  resources.  This  can  be  achieved  by  sorting  queued  traffic 
within  end  systems  and  intermediate  systems  during  periods  of  anticipated  or  real  congestion. 
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Preesiptioo  of  resources  on  be  achieved  by  discarding  NPDUs.  Encoding  of  the  precedence  and 
preemption  parameter  and  the  error  conditions  ire  specified  in  ifae  STANAG. 

•  MnittenAwint  gmcfljfln.  It  is  necessary  to  allocate  and  reserve  address  space  for  multicasting  red 
broadcasting  in  IP;  extensions  to  IP  to  implement  and  manage  multicasting  are  still  to  be  defined.1 
Coocepts  for  multicast  addresses  are  described  in  detail  in  the  STANAG. 


Table  J-2.  Areas  of  Deficiencies  and  Enhancements  for  STANAG  4253 


Til  Muttihoming.  In  the  interest  of  survivability,  an  and  eystem,  identified  by  a  single  “logical*  network 
address,  may  need  to  be  connected  at  several  Subnetwork  Points  of  Attachment  (SNPAa)  either  with  more 
than  one  link  into  the  same  subnetwork  or  with  links  into  several  subnetworks.  Routing  management 
functions  will  be  needed  in  order  to  determine  the  SNPA  to  be  used.  Enhancements  for  routing 
management  (W  any),  maintenance  of  connections,  and  data  transfer  processing  are  for  further 
study.  Annex  D  defines  extensions  for  logical  network  addressee. 

(2)  Mobile  Hosts.  This  requirement  is  for  end  systems  identified  by  a  single  logical  address  to  be  able  to 
connect  to  different  SNPAs,  although  only  one  connection  may  be  in  use  at  any  one  time,  in  this  case  it 
may  not  be  possible  to  determine  in  advance  which  subnetwork  links  will  be  involved  in  establishing 
connections  associated  with  a  particular  subscriber  address.  The  Network  Layer  addressing  is  extended 
in  this  STANAG  to  support  logical  network  addresses  that  may  identify  more  than  one  NSAP. 
Enhancemente  for  routing  management  (if  any),  maintenance  of  connections,  and  data  transfer 
processing  are  for  furthar  study.  Annex  D  defines  extensions  for  logical  network 
addreeeee. 

(3)  Multiendpoint  Connections.  To  economize  on  network  bandwidth  and  increase  speed  of  detivery,  an 
application  that  involves  sending  the  same  data  to  a  number  of  destinations  wHI  require  a  multi-addreeaing 
service  (multipeer  data  transmission)  within  the  Network  Layer,  which  provides  ether  selective  addressing 
or  broadcast  fadfities.  The  Network  Layer  addressing  is  extended  in  Annex  D  of  tills  STANAG  to  support 
multicast  addresses  that  may  identify  more  than  one  NSAP.  Enhancemente  for  multipeer  data 
transmission  are  for  further  study. 

(4)  Internetworking.  No  deficiencies  in  the  application  of  the  dvl  internetworking  standards  to  military 
requirements  have  been  identified. 

(5)  Meneoement.  Additional  management  facilities  may  be  required  to  support  the  other  military 
enhancements.  Military  enhancements  of  the  ISO  Network  Layer  management  objects  are  for 
further  study. 

(6)  Security.  The  ability  is  required  to  signal  the  security  label  of  each  network  connection  and  each 
connectionless  sendee  data  unit.  The  security  classification  wll  remain  constant  throughout  the  Bf a  of  a 
connection.  Enhancements:  the  security  label  for  a  network  connection  or 
connectionless  service  data  unit  may  be  signalled  as  a  protection  QOS  parameter. 

(7)  BflbuNn—  and  flualftt  Si  Sendee.  The  ahttv  to  autvhre  physical  dumps  and  denial  el  service  attacks 
and  to  route  around  damaged  or  partitioned  networks  is  required  for  military  systems.  Military 
enhancemente  to  Network  Layer  management  functions  for  robustness  are  for  further  study.  No 
requirement  for  miltary  enhancement  for  the  Network  Layer  sendee  for  QOS  has  been  identified. 

(8)  Precedence  qnd  Preemption.  No  requirement  for  rndtiry  enhancement  has  been  identified  beyond  the 
priority  QOS  parameter  defined  in  ISO  8348. 

(9)  BaajJ3mttj£amiMi^  Enhancemente  for  real-time  communications  ate  ter  further  study. 


Source:  Draff  STANAG 4253, 19  April  1993,  NATO  UNCLASSIFIED. 


Annex  E  on  CLNP  does  not  specify  the  use  or  noo-use  of  multicasting  or  broadcasting,  but  the  Annex 
allocates  and  reserves  address  space  for  tbese  two  capabilities.  The  discussion  of  multicast  encoding  addresses  the 
following  topics:  multicast  addresses  for  subnetworks,  multicasting  addressing  for  areas,  multicasting  addresses  for 
domains,  multicasting  error  cooditioas,  and  multicast  subscription  options  (TBD). 

Annex  E  also  contains  a  draft  PICS  proforma  (Appendix  1)  and  an  informative  discussion  of  CL  network 
routing  exchange  protocols  (Appendix  2).  A  four-page  informative  appendix  (Appendix  3)  discusses  security  options 
for  CLNP — these  options  are  baaed  on  logical  extensions  of  appropriate  fields  (Le„  Basic  Portion  fields  and  Extended 
Portion  fields)  witbin  the  provisions  of  ISO  8473.  A  congestion  notification  function  is  also  described  in  Annex  E. 


1  Draft  STANAG  4263  identifies  US  DoD  RFC  1034,  Host  Extensions  for  IP  (DoD)  Multicasting,  as  the  source  for 
descriptions  of  the  required  extenriooe  to  ISO  IP.  See  Appendix  H. 
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Table  J-3.  Military  Enhaneamants  Idantifiad  lor  Annax  C  of  STANAG  4263 


(1)  SifiUdtt-  The  use  of  the  network  service  Protection  Quality  of  Service  parsmetar  to  associate  a  security 
level  with  a  network  connection  0  (or  furthar  study. 

(2)  Precedence  and  preemption.  MBitary  systems  using  OSI  protocols  need  to  be  able  to  signal  priority  at  data 
transferred  over  a  connection,  the  priority  to  gain  a  connection,  and  the  priority  to  keep  a  connection.  The 
priority  thereby  signaled  may  then  be  used  to  determine  the  precedence  of  data  and  to  control  the  use  of 
and  allocation  of  network  resources.  Use  of  priority  facility  is  optional  in  this  STANAG,  but  may  be 
enforced  by  specific  profiles.  Priority  values  are  integers  in  the  range  0  to  14,  with  255  meaning 
"unapedied."  Annax  C  specifies  the  procedures  to  be  used  when  a  subnetwork  does  and  alt  amatively 
does  not  implement  precedence  and  preemption  faettties. 

(3)  “■‘tfrfflhg  MuMhoming  may  be  achieved  through  the  X.25  Hunt  Group  optional  user  facHty,  provided  the 
SNPAe  eorreepondbtg  to  the  various  "homes'  can  be  defined  as  members  of  an  X25(1988)  Hunt  Group. 
The  use  of  the  Hunt  Group  faclity  for  muMhoming  is  transparent  to  the  OSI  network  service  ucer.  Three 
types  of  Network  Layer  management  fadWee  are  specified  in  the  STANAG  to  support  the  use  of  a  Hunt 
Group:  configuration.  muMhominfl  subscription  options,  and  multihoming  registration. 

Source:  Draft  STANAG  4283, 19  April  1993,  NATO  UNCLASSIFIED. 


5.  TRANSPORT  LAYER  STANAGS 

STANAG  42S4  (March  1993)  provides  the  transport  service  definition.  The  CO  transput  service  (Amex 
Q  is  based  on  ISO  8072.  The  CL  transport  service  (Annex  D)  is  based  on  ISO  8072/ADI  (with  the  restriction  that 
the  nose  of  paragraph  15.2.3  is  not  retained). 

Annex  E  (informative)  of  STANAG  4254,  Real-Tune  Transport  Service  (RTTS),  has  been  proposed  to 
fulfill  the  real-tiine  military  features  far  NATO  military  systems.  Specifically,  RTTS  is  designed  to  offer  more 
fiaictinnaHty  to  such  services  as  connection  service  and  data  transfer  service  and  to  provide  additional  services  such  as 
synchronization  and  management  RTTS  provides  services  for  broadcasting,  selective  broadcasting,  and 
concentration.  Appendix  1  of  Annex  E,  Definition  of  the  Real-Time  Transport  Service  (RTTS)  Provided  by  the 
Transfer  Layer,  uses  concepts,  terminology,  and  structure  similar  to  ISO  8072  for  transport  Classes  0, 1,  and  2. 
RTTS  appears  to  impact  more  than  a  single  layer  (Layer  4)  and  does  not  appear  to  fully  conform  to  the  Basic 
Reference  Model  ISO  7498. 

Deficiencies  snd  required  enhatermcnti  in  seven  areas  ate  noted  in  STANAG  4254  for  both  CO-modc  and 
CL-mode  transport  services  as  shown  in  Table  J-4  (internetworking  is  not  applicable). 

Tnbln  J-4.  Deficiencies  and  Enhaneamants  idantifiad  for  8TANAG  4254 


No 


bMa  boat  Saw.  Tha  tianaport  aarvica  la  net  impact  ad  bv  thaaa  raouiramanta. 
required. 

etiona.  Tha  tranaport  aarvica  doaa  not  provide  any  aarvica  or  function  ralatad  to 
muMaddrasaing.  To  apadfy  tha  addraaaaa  of  partidpanta  In  a  muMpeer  connectionless  transmission,  tha 


(2)  MuMendnalnt 

muMaddraaaing 

Group  Address  can  be  raeoived  Into  a  number  of  ordinary  addraaaaa  or  tha  address  paramstsrs  in  the 
ssnrios  dsflnMon  can  bs  redsfinsd  to  psmnlt  ths  uss  of  a  list  of  addressss  rethsr  than  juat  one 

(3)  Natwotfcfryttw  functions.  System  management  services  and  definitions  of  managed 

objects  are  in  progress  in  ISO  and  seem  suitable  for  ths  NATO  environment.  Some  specific  military 
objects  and  functions  are  to  ba  defined. 

(4)  Security  la  addressed  in  a  dasslled  annex. 

(5)  p«h«.— »—■  mmi  Dummy  ni  tuwrfw  (QOS).  No  enhancements  are  required.  QOS  parameters  are 
provided  for  data  transfer  aarvica  enaMng  tha  user  to  control  and  check  tha  QOS.  This  parameter  is 
neaotiated  during  the  connection  eetabiiahmen!  ohose 

riwiiwtmnww  a^asvwree  ss^m  as  s  wwrewiwrniiiwiK  irnmrei 

(9)  n™*— and  preemption.  No  enhancements  required.  A  QOS  parameter  is  provided  to  express 

ule  pOOlWy  W  B  iINnEpOfl  COlWre^wOllf 

(7)  n— m»»f  ■««<  ***#*»!  wimwi wir-aiftns  In  reaMime  communications  (there  le  a]  requirement  to  have  short 
transit  delay.  There  is  also  a  requirement  for  such  services  as  sampling  process  data  transmission, 
periodic  data  transmission,  and  synchronization  service,  which  are  not  provided  by  the  ISO  transport 
service.  The  requirement  of  a  short  transit  delay  impiee  no  augmentation  of  data;  the  length  of  the  TSOU 
must  be  limited  for  that  typo  of  communication.  For  reaMime  communications,  the  definition  of 
services  is  for  further  study  (it  could  bo  baaed  on  the  Real-Time  Tranaport  Service  in  Annex  E).  For 
tactical  communicatione.  ISO  transport  services  are  suitable. _ 


Source:  DreR  STANAG  4254, 19  Mwch  1993,  NATO  UNCLASSIFIED. 
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STANAG  4264  (March  1993)  provides  the  transport  protocol  specification.  The  connection-oriented 
transport  protocol  (Annex  Q  is  based  on  ISO  8073.  The  deficiencies  snd  enhancements  to  seven  of  the  military 
features  (internetworking  does  not  apply)  are  given  in  Table  J-5. 

Tobin  J-5.  OnfieinneiM  and  Enhancnmanta  Idnntlflnd  lor  Annax  C  of  STANAG  4254 


fit  HuBEmB  and  55BS  hot  ayatama.  Tha  protocol  shall  hava  tha  rocowry  maehaniam  at  Cl— at  1.  a.  or 
4  in  the  ease  where  the  Network  Service  Provider  releases  the  network  connection  each  time  the  host 
system  changes  SNPA  and  the  QOS  requirement  specifies  low  probability  of  unexpected  connection 
release.  If  the  Classes  0  or  2  are  used,  the  recovery  of  the  connection  shal  be  provided  either  in  the 
Network  Layer  or  in  the  Application  Layer.  If  a  host  system  has  more  than  one  NSAP  or  needs  the 
capabiflty  to  maintain  communication  with  hosts  associated  with  multiple  NSAPs,  then  it  shall  support 
Classes  1,  3,  or  4  with  the  multihoming  enhancements  specified  in  Appendbc  2  to  Annex  C.  These 
enhancements  allow  a  transport  connection  to  be  associated  with  multiple  NSAP  pairs  and  shal  be  used  to 
meat  the  transport  connection  reelience  requested  by  the  transport  service  user. 

(2)  MuMandnoint  connections.  Savings  in  time  and  bandwidth  can  only  be  achieved  H  mechanisms  are 
introduced  into  layers  that  inherently  possess  the  ability  to  support  communications  to  multipia 
destinations  simultaneously  (Layers  2  and  3).  At  present,  only  indhridual  addressee  can  be  used  by  the 
CO  transport  protocol  and  group  addresses  or  ksts  of  addresses  are  not  supported  by  this  protocol,  even 
in  the  case  where  such  address  schemes  are  offered  by  the  Network  Service. 

(3)  Natworktev^tn  jpmggnMBfl  Specific  mWtary  managed  objects  for  the  Transport  Layer  wM  be  specified 
when  they  are  identified.  They  will  be  specified  as  extensions/ modifications  to  the  civilian  managed 
objects. 

(4)  Security.  Security  deficiencies  and  enhancements  are  specified  in  a  classified  annex. 

(5)  Robustness  and  QtmBtv  of  Service  fQQSI.  Transport  Layer  specifications  of  the  mechanisms  needed  to 
reepect  the  QOS  requirements  are  for  further  etudy. 

(6)  Precedence  and  preemption.  Annex  C  describes  mechanisms  for  encoring  a  priority  parameter, 
maintaining  QOS,  providkig  transport  connection  preemption,  and  defining  adrftional  reason  values. 

(7)  Real-time  and  tactical  communications.  The  real-time  transport  protocol,  used  over  a  CONS,  is  to  be 
defined.  The  real-time  transport  protocol,  used  over  a  CLNS  wM  be  defined  in  Annax  F  (informative); 
details  are  to  be  defined. 

Source:  Draft  STANAG  4264,  October  1991.  NATO  UNCLASSIFIED. 

Annex  D  specifics  the  cormecooniess  transport  protocol,  based  on  ISO  8602.  Enhancements  are  the  san 
as  in  Annex  C  (Table  J-5  above)  with  the  following  two  exceptions: 

•  Mntritinmeri  amt  Mobil*  Hn«r  Sv«iwn«  Since  do  data  acknowledgment  is  provided  by  (be  service,  the 
protocol  is  not  affected  when  a  remote  host  system  changes  its  SNPA  and  is  not  reachable 
temporarily. 

•  and  Pm«nprinn  Transport  Layer  specifications  of  the  mechanisms  involved  for  the 
management  of  the  priority  are  for  (writer  study. 

Annex  E  specifies  the  connection-mode  transport  protocol  over  CONS,  based  on  ISO  8073  and  ISO 
8073/AD2  {Class  Four  Operation  Over  Connectionless  Network  Service)  using  TP4.  Enhancements  are  die  same  as 
in  Annex  C  (Table  J-5)  with  the  following  exception: 

•  u"lt|lnMH  "fl  Host  Systems.  In  the  case  of  hosts  with  multiple  SNPAs  and  a  single 

NSAP,  the  protocol  specified  in  ISO  8073  and  807 3/ ADI  is  adequate,  provided  there  are  automated 
network/system  management  mechanisms  that  manage  SNPA  changes  and  reconfigure  the  network 
service  provider’s  routing  function.  Hosts  that  have  multiple  NSAPs  or  need  to  communicate  with 
hosts  having  multiple  NSAPs  shall  support  the  ISO  8073  and  8073/ ADI  protocol,  including  the 
ability  to  associate  a  transport  connection  with  more  than  one  NSAP  pair,  as  is  explicitly  stated  in 
Appendix  2  to  Annex  C.  The  availability  of  additional  NSAP  pairs  shall  be  used  to  meet  the 
transport  comedian  resilience  requested  by  the  transport  service  user. 

Annex  F  of  STANAG  4264,  Real-Time  Transfer  Protocol  Over  Connectionless  Network  Service,  is  still  to 
be  defined.  It  is  intended  to  be  used  with  military  real-time  LANs,  soch  as  those  specified  by  STANAG  3838  (baaed 
on  MIL-STD-1553-B  that  is  uaed  as  a  data  boa  in  aircraft  systems).  The  RTTS  protocol  has  been  (focussed  as  a  new 
work  item  in  SC6  but  has  not  yet  been  registered  in  ISO.  It  is  available  imder  the  French  reference  GAM-T-103-B. 

4.  SESSION  LAYER  STANAGS 

The  two  Seaakm  Layer  STANAGs  (4255  and  4265)  have  been  developed  by  WG2  with  the  US  serving  as 
editor.  Both  these  STANAGs  were  ratified  without  military  features. 
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STANAG  4255  is  based  on  ISO  8326,  Basic  Connection-Oriented  Session  Service  Definition: 
STANAG  4265  is  based  an  ISO  8327,  Basic  Connection-Oriented  Session  Protocol  Specification.  Fwh  has  an 
annex  reserved  tor  connectionless  session  services.  The  only  military  deficiency  areas  identified  in  draft 
STANAGs  are  far  security  sod  nmttcndpoint  connection: 

•  Seenritv  A  mechanism  for  providing  graceful  closure  may  be  required  by  NATO  in  the  long  term. 
At  present,  ibis  requirement  is  insufficiently  refined  to  allow  a  service  realization  Therefore,  no 
enhancement  of  ISO  security  measures  can  be  provided  at  this  time. 

•  MnhiwMWwit  orwituftirwi  ISO  is  currently  considering  multipeer  data  transmission  requirements  for 
the  Session  Layer.  This  activity  will  be  monitored  by  the  developer  of  this  STANAG,  and  this 
paragraph  will  be  updated  as  developments  warrant.  An  enhancement  requirement  is  contingent  upon 
ongoing  developments  within  ISO. 


7.  PRESENTATION  LAYER  STANAGS 


The  two  Presentation  Layer  STANAGs  (4256  and  4266),  together  with  STANAGs  for  ASN.l  (STANAG 
4258)  and  the  Basic  Encoding  Roles  (BER)  for  ASN.l  (STANAG  4259)  have  been  ratified  without  military  features. 

STANAG  4256  is  initially  based  on  ISO  8822,  Connection-Oriented  Presentation  Service  Definition-, 
STANAG  4266  is  based  on  ISO  8823,  Connection-Oriented  Presentation  Protocol  Specification.  Each  has  an  annex 
reserved  for  connectionless  session  services.  Potential  deficiencies  have  been  noted  in  three  areas  for  these 
STANAGs: 

•  Security  (Annex  B).  NOSA  has  placed  additional  security-related  services  in  the  Presentation  Layer, 

but  these  are  not  yet  defined  in  detail.  Modifications  are  anticipated  in  the  ISO  standards  following 

ISO  7498-2,  which  may  meet  the  emerging  military  requirements.  No  security  enhancement  to  the 

ISO  Presentation  Layer  is  currently  available.  However,  as  solutions  are  available  this  STANAG  will 
- ■  ■ 
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No  deficiencies  noted  (subject  to  change  dependent  upon  the 
ability  of  the  lower  layers  to  support  *4*  feature). 

?'  dificat^oS  will  be  needed  to  the  Presentation  Layer  if  multiendpoint 
i  are  required  hr  a  dementaiion.  but  no  specific  requirements  have  yet  been  identified. 
Modifications  win  lie  mite  to.  ‘  isn  «fn<lprril  im*  mnlrtpr  niQfft  in  1ST>  hm 

been  progressed. 

No  deficiencies  were  found  in  the  ASN.l  (STANAG  4258)  and  ASN.l  BER  (STANAG  4259)  stndaids, 
sad  no  enhancements  were  recommended.  STANAG  4259  observed  that  additional  sets  of  encoding  rules  for  ASN.l 

may  be  required  for  specific  applications  giving  either  rarnpraietl  (minimum  volume^  nr  iurrypteri  enraHingc  No 
specific  reqnimncnti  in  this  area  were  identified. 


8.  APPLICATION  LAYER  STANAGS 

Two  STANAGs  (4257  and  4267)  were  originally  planned  to  address  application  service  dements,  such  as 
ROSE,  RTSE,  and  ACSE.  No  drafts  of  these  documents  has  yet  been  produced.  Other  STANAGs  are  being 
prepared  separately  for  MMHS  (4406),  Systems  Management  (4407),  etc. 
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Joint  Interoperability  and  Engineering  Organization, 
Center  for  Standards 

Information  Processing  Standards  Directorate 
ATTN:  TBE  (CAPT  Richard  Petersen,  Dap.  Dir) 
Parkridge  III  Building,  10701  Parkridge  Boulevard 
Reston,  VA  22091 -4398 

JSARO  1 

ATTN:  Army/Navy/USMC/AF/NSA/DIA 
Parkridge  III  Building,  10701  Parkridge  Boulevard 
Reston.VA  22091 -4398 

Director.  Defense  Information  Systems  Agency  1 
Joint  Interoperability  and  Engineering  Organization, 
Center  for  Standards 
ATTN:  TB  (Mr.  Gary  Koemer) 

Parkridge  III  Building.  10701  Parkridge  Boulevard 
Reston.  VA  22091  -4398 

Director,  Defense  Information  Systems  Agency  1 
Joint  Interoperability  and  Engineering  Organization, 
Center  for  Standards 
ATTN:  TBC  (Mr.  Norton  Bragg) 

Parkridge  III  Building,  10701  Parkridge  Boulevard 
Reston.  VA  22091 -4398 

Director,  Defense  Information  Systems  Agency  1 
Joint  Interoperability  and  Engineering  Organization 
ATTN:  TOP  (Mr.  Jimmie  Lae) 

11440  Isaac  Newton  Square,  Suits  210 
Reston,  VA  22090-5006 

Director,  Defense  Information  Systems  Agency  1 
Joint  Interoperability  and  Engineering  Organization 
ATTN:  Mr.  Alan  Petaman 
Parkridge  III  Building.  10701  Parkridge  Boulevard 
Reston,  VA  22091-4398 

Director,  Defense  Information  Systems  Agency  1 
Joint  Interoperability  and  Engineering  Organization 
ATTN:  TBBC  (Mr.  8»  Scott) 

Bdkflng  286  (Russel  Hal) 

Fort  Monmouth,  NJ  07703-6613 

Director,  Defense  Information  Systems  Agency  1 
Defense  Information  Systems  Management  Ctr 
Operations,  Customer  Relations,  and  Service 
ATTN:  Mr.  John  Edeti,  Acting  Deputy  Director 
701  S.  Court  House  Road 
Arlington,  VA  22204-2199 


Director,  Defense  Information  Systems  Agency  1 
Defense  Network  Systems  Organization  (DNSO) 

701  S.  Court  House  Road 
Arlington.  VA  22204-2199 

Director,  Defense  Information  Sendees  Org.  4 
ATTN:  DISCAJAP  (Mr.  John  Keane) 

1951  Kidwel  Drive 
Vienna,  VA  22182-3930 

Director,  Joint  Interops rabifity  Test  Center  1 

Tactical  Communications  Division 
ATTN:  JfTC/TC8  (Mr.  Lao  Hanson) 

Fort  Huachuca,  AZ  85613-7020 

Director,  Joint  Interoperabttty  Test  Center  1 

Tactical  Communications  DMsion 
ATTN:  JTTC/rCOB  (Mr.  Dwaine  Huewe) 

Fort  Huachuca,  AZ  85613-7020 

National  Communications  System  1 

ATTN:  Code  NT  (Dennis  Bodson,  Frank  McCMand, 
Robert  Feniehel) 

701  South  Court  House  Road 
Arlington,  VA  22204-2198 

Director,  Defense  Mapping  Agency  3 

ATTN:  Tl.  Mai  Stop  A-10  (Mr.  Charles  Roswsl) 

8613  Lee  Highway 
Fairfax,  VA  22031-2137 

NATO  Integrated  Communications  Systems 

Management  Agency  1 

NACISA 
ATTN:  USOCFO 
APOAE  09724 

Director.  National  Security  Agency  3 

ATTN:  V5  (Mr.  Harold  Staton,  Gerald  Baiey) 

9800  Savage  Road 

Foit  George  Meade.  MD  20755-6000 

Director,  National  Security  Agency  2 

ATTN:  V3  (Mr.  Dick  McAllister) 

AjtDOrt  Square  10 

FortGeotgeMeade,  MD  20755-6000 

Director,  National  Security  Agency  3 

ATTN:  19  (Mr.  Dais  Nunley) 

AJreort  Sowars  20 

FortGeorge  Meade,  MD  20756-6000 

Director,  National  Security  Agency  1 

ATTN:  111  (Mr.  S.  J.  Buchanan) 

OPS  3 

Fort  Georgs  Meade,  MD  20756-6000 

Director,  National  Security  Agency  2 

ATTN:  R23  (Mr.  Doug  Maughan) 

Fort  Georgs  Meads,  MD  20756-6000 

Director,  National  Security  Agency  1 

ATTN:  R536  (Mr.  Ray  McFarland) 

Fort  Georgs  Meade,  MD  20756-6000 
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Director,  National  Security  Agency  1 

ATTN:  191  (Me.  Tammy  Mannartno) 

9600  Bangs  Road 

Fort  George  Meade,  MD  20786-6000 

Director,  Defence  Inteipence  Agency  2 

D1A  Management  Board 
ATTN:  S-02  (Maj  Qtrert  Armour) 

Washington,  DC  20340-5100 

Director,  Defenaa  Intelligence  Agency  2 

INCA  Project  Office 

ATTN:  Ma«  Stop  W940  (Mr.  George  Endteott) 
Washington  Building 
7796  Old  Springhouee  Road 
McLean,  VA  22102 

Director,  Defence  Logietica  Agency  1 

ATTN:  DLArZIA 

Cameron  Station 

6010  Duke  Street 

Alexandria,  VA  22312-6101 

Director,  Defenaa  Logietice  Agency  1 

ATTN:  DLA-ZID/DRDO  (Mr.  George  Pogharian) 

6303  Little  River  Tumpflce  at  Beauregard  Street 
Suite  310 

Alexandria,  VA  22312-6040 

Director,  Defence  Logistics  Agency  1 

System*  Automation  Center 

ATTN:  DSAC-RSB  (Mr.  Clyde  Groeearth) 

P.  O.  Box  1605 
Cokuribue,  OH  43216-6002 

BaNstic  Mieale  Defence  Organization  (BMDO)  1 

The  Pentagon.  Room  1E1037 
WaaMngton,  DC  20301-7100 

Inatitut*  for  National  Strategic  Studies  1 

ATTN:  Or.  Stuart  Johnaon,  Dir  Strategic  Concepts 
Development  Center  Dr.  Martin  Ubidd 
National  Defense  University,  Room  209 
Fort  McNair 

Washington,  DC  20319 

Information  Resources  Management  Colege  1 

Department  of  Information  Technology 

ATTN:  Dr.  J.  Couture,  Chair 

National  Defense  University,  Room  136 

Fort  McNair 

WaaMngton,  DC  20319 

Armed  Force*  Staff  College  1 

C3  Division  (AFSCC30) 

ATTN:  UCol  M.  L  Vanpelt,  Chair 
Norfolk.  VA 

Director.  DiSA  1 

ATTN:  XL  (Mr.  Robert  Compton) 

P.O.  Boa  1606 
Columbus,  OH  43216-6002 

US  Coast  Guard  1 

ATTN:  ComdtG-TA 
2100  Second  Street.  SW 
Washington,  DC  20593-0001 


Information  Handfcig  Commttse,  ICS 

Mr.  Georgs  W.  Rogers,  Jr..  Vice-Chairman  1 

Washington,  DC  20606 

Department  of  the  Army 

HQDAOOISC4  15 

InteroperaMity  and  Standards  Office 
ATTN:  SAIS-ADO  (LTC  D.S.  Woffindsn) 

The  Pentagon,  Room  1C638 
Washington,  DC  20310-0107 

HQOAODISC4  1 

InteroperabDty  and  Standards  Office 
ATTN:  SAIS-ADO  (Mr.  L  Tom  Hendrick) 

The  Pentagon,  Room  1C638 
Washington,  DC  20310-0107 

HQDA  DCS  Operations  and  Plana  1 

Director  of  Requirements 

ATTN:  DAMO-FOQ  (Mr.  John  Pgnowski) 

The  Pentagon,  Room  3C481 
Washington,  DC  20310-0107 

Commander.  US  Army  Signal  Career  1 

Directorate  of  Combat  Development 
ATTN:  AT2H-CD  (COL  Forrester) 

Fort  Gordon,  GA  90905-6090 

Commander,  US  Amy  Signal  Center  1 

Battle  Command  Battle  Laboratories 
ATTN:  ATZH-BL  (COL  Nfcholeon) 

Fort  Gordon,  GA  30906-6090 

ONCUSAREUR  1 

ATTN:  AEAM-AR-AR 
APOAE  09403 

Commander,  US  Army  Pacffic  Command  1 

ATTN:  AP94-PRA(Mr.  JoeNg) 

Fort  Shatter.  HI  96858-6100 

Commenting  General,  U  S.  Army  TRADOC  1 

ATTN:  ATCD-C8  (Mr.  Richard  HU) 

Fort  Monroe,  VA  23651-5000 

Commencing  General,  U.S.  Army  TRADOC  1 

Director  of  Information  Management  (DOIM) 

ATTN:  ATTM-IAP  (Mr.  Rley  Beet) 

Fort  Monroe,  VA  23651-6000 

Commenting  General.  U.S.  Army  TRADOC  i 

ATTN:  ATCD-GC  (Mr.  PMI  Caaey) 

Fort  Monroe,  VA  23651-5000 

Commander,  USAISEC  1 

ATTN:  ASQB-OTD  (Mr.  M8ts  Gentry,  Technical 
Director) 

Fort  Huachuca,  AZ  85613-6300 

Director,  US  Army  Information  Systems 

Command  (USAISC)  1 

Software  Development  Center 
ATTN:  A9QB-SIS  (Mr.  Dick  Fair) 

Fort  Huachuca,  AZ  8561 3-6450 
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Corwnondsr,  USAISEC 

ATTN:  ASQB-SIS  (Mr.  Jim  Starkey) 

Fort  Huachuca,  AZ  S56 13-5300 

Diroctor,  USAISC-Pontagon 
ATTN:  ASQNS-TS-0  (Mr.  Thomas  J.  Kenavan) 
Tho  Pentagon,  Room  BE1018 
Washington,  DC  203KF3063 


Commander.  CECOM  1 

PM  CHS 

ATTN:  SFAE-CC-CHS  (Mr.  Sian  Levine) 

Ft  Monmouth,  NJ  07703-6000 


Commandar,  CECOM  1 

ATTN:  SFAE-CCOPEO  CCS  (Mr.  Mfcs  AJbaral) 

Ft  Monmouth,  NJ  07703-6000 


Commandar,  USAiSMA  1 

ATTN:  Mr.  Frank  Dwuist 
Fort  Monmouth,  NJ  07703 

Commandar,  US  Army  Oparationai  Tost  and 

Evaluation  Command  1 

ATTN:  Dr.  Henry  Dubin,  Technical  Director 
Park  Office  Center,  Room  1420 
4501  FordAvanua 
Alexandria,  VA  22302-1458 

Headquarters,  Dapartmant  of  tha  Army  1 

PEO-IEW 

ATTN:  Mr.  Daa-Woo  Laa 
VHFS 

Warrantor),  VA  22188-5115 


Commandar,  CECOM  2 

PM  FATDS,  Tachnical  Management  Directorate 
ATTN:  SFAE-OC-FS-TMD  (Hanry  Saphow.  Mfee 
Simpaon) 

BuHdng548 

Ft  Monmouth,  NJ  07703-6000 

Commander,  CECOM  1 

PM  OPT  ADS 

ATTN:  SFAE-CC-OPTDS  (Mr.  Paul  Ulrick) 

Ft  Monmouth,  NJ  07703-6000 

Diractor,  Joint  Tactical  Fusion  Program  1 

ATTN:  PM  ASAS  (Mr.  Vinca  Drobney) 

1 618  Andamon  Road 
McLean,  VA  22102-1616 


US  Amny,  PEOSTAMIS  1 

ATTN:  SFAE-PS-S  (Mr.  Michael  Fatal) 

Fort  Belvoir,  VA  22060-5895 

Commandar,  U.S.  Army  Combined  Arme  Center  1 
ATTN:  ATZL-CDC-A  (Mr.  Frank  Torree) 

Ft  Leavenworth,  KS  68027-3600 

Commandar,  U.S.  Army  Combined  Arme  Center  1 
ATTN:  TSM-ACCS  (COL  Tom  Dials,  CptH.  Matthews) 
Bufldtog  52  (Grant  Hal),  Room  128 
Ft  Leavenworth,  KS  66027-3600 

Director,  US  Amy  RDEC  1 

ATTN:  AMSEL-RD  (Mr.  Robert  Giordano) 

BuUdtefl  1210 

Ft  Monmouth,  NJ  07703-5000 

Director.  US  Amy  RDEC  1 

Software  Engineering  DMaion 

ATTN:  AMSEL-RD-SE-D  (Mr.  Dennis  Turner) 

Bulking  1210 

a  Monmouth,  NJ  07703-5207 

Diractor.  US  Amy  RDEC  1 

Software  Engineering  Division 
Command  and  Control  Information  Systems 
ATTN:  AMSEL-RD-G2-D  (Mr.  Bruce  MBor) 

Bulking  1210 

a  Monmouth,  NJ  07703-5207 

Commandar,  CECOM  1 

pen  Communications 

■Sr  W* IP* Pn VW 

ATTN:  Mr.  Nefl  Atkinson,  Deputy  PEO 
a  Monmouth,  NJ  07703-5000 

Commander,  CECOM  1 

ATTN:  8FAE-CG/PEO  CCS  (MGan  Campbel) 
a  Monmouth,  NJ  07703-5000 


Commander,  CECOM  1 

Software  Engineering  Directorate 
ATTN:  AMSEL-RD-SE-AIN  (Mr.  JackZavin) 
a  Monmouth,  NJ  07703-5000 

Commander,  CECOM  1 

ATTN:  Mr.  J.  Onufer 
a  Monmouth,  NJ  07703-6000 

Commandar.  CECOM  1 

C2  Systema  Integration  Directorate 
ATTN:  AMSEL-RD-G2-PM  (Mr.  Jack  Plant) 
a  Monmouth,  NJ  07703-6000 

Department  of  the  Army  AIRMICS  1 

ATTN:  Mr.  WMrad  Fong,  Dan  Hocldng 

1 15  O’Keefe  Buidteg 

Georgia  Institute  of  Technology 

Atlanta,  GA  30332-0600 

Commander  AMC  RDEC  1 

ATTN:  SMCAR-FSC  (Dr.  T.  H.  Chin) 

BuMng  352  North 
Dover,  NJ  07801-5001 


Commander.  Corps  of  Enginaara  1 

Directorate  of  Mormatkin  Management 
Infrastructure  Support  Division 
ATTN:  CEA4-SE  (Mr.  Webster  Smkh) 

Pulaald  BuMng,  Room  6120C 
20  Maaaachuaatta  Avenue,  NW 
Washington.  DC  20314-1000 


CNsf  of  Naval  Operations  1 

aieuAna  wiul 

j  WIQ 

ATTN:  N8  (Dr.  J.  R.  Davis.  Chief  Scientist) 

Tha  Pentagon,  Room  4G671 
Washington,  DC  20360 
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Chief  of  Naval  Operation*  1 

Director,  Space  and  Electronic  Welfare 
Information  Tranafer  DMaion 
ATTN:  N61  (COL  Edward  R.  Palmquiet,  Jr.) 

The  Pentagon,  Room  5AS86 
Washington,  DC  20360 

Chief  of  Naval  Operation*  1 

Director,  Space  and  Electronic  Warfare 
Information  Syatem  Requirement* 

ATTN:  N62  (CAPT  WKam  C.  Uebe) 

The  Pentagon,  Room  5E569 
Washington,  DC  20350 

Chief  of  Naval  Operations  1 

Director,  Space  and  Electronic  Warfare 
NCTS-A  Requirements 
ATTN:  N62J  (CDR  James  R.  Kirkpatrick) 

The  Pentagon,  Room  SES23 
Washington,  DC  20350 

Chief  of  Naval  Operation*  1 

Director,  Space  and  Electronic  Waif  are 
Tactical  C3I  Systems  Interoperabflity  Coord. 

ATTN:  N62T  (Mr.  J.  D.  Ferrefl) 

The  Pentagon,  Room  5E523 
Washington,  DC  20350 

Chief  of  Naval  Operatione  1 

Director,  Space  and  Electronic  Warfare 
Information  Resource  Management  Division 
ATTN:  N65  (CAPT  P.  A.  Calahan) 

The  Pentagon.  Room5A734 
Washington.  DC  20350 

HQ  Department  of  the  Navy  1 

Navy  Information  System  Management  Center 
ATTN:  ADM  Hatonan.  Commander,  Rebecca  Wade 
Crystal  Gateway  «2 

1225  Jefferson  Davis  Highway,  Suita  1500 
Arlington,  VA  22245 

HQ  Department  of  the  Navy  1 

Navy  Information  System  Management  Center 
ATTN:  Code  03  (Maushal  Potter,  John  Hooder) 
Crystal  Gateway  #2 

1225  Jefferson  Davis  Highway,  Suits  1500 
Arlington,  VA  22245 

HQ  Department  of  the  Navy  1 

Information  Technology  Acquisition  Center 
ATTN:  Robert  A.  Green,  Standards  Division 
Washington  Navy  Yard,  Building  178 
Washington,  DC  20374-1682 

Commander,  Space  and  Naval  Warfare  Systems 
Command  (SPAWAR)  1 

ATTN:  P080  (CAPT  J.  A.  Gauss) 

Crystal  Park  #5,  Room  30 
2461  Jefferson  Davis  Highway 
Arlington,  VA  22245-5200 


Commander,  Space  and  Naval  Warfare  Systems 
Command  (SPAWAR)  1 

ATTN:  PMW-161  (CAPT  Boetian) 

Crystal  Parte  #5,  Room  421 
2451  Crystal  Drive 
Arlington,  VA  22245-5200 

Commander.  Space  and  Naval  Warfare  Systems 
Command  (SPAWAR)  1 

ATTN:  231/2B3  (CDR  Michael  C.  Aaby) 

Crystal  Parte  *5,  Room  701 
2451  Crystal  Drive 
Arlington,  VA  22245-5200 
> 

Commander,  Spaoe  and  Naval  Warfare  Systems 
Command  (SPAWAR)  1 

ATTN:  322-15  (Mr.  Robert  D.  Koiadd) 

Crystal  Parte  *5,  Room  701 
2451  Crystal  Drive 
Arlington,  VA  22245-5200 

Commander,  Naval  Research  Laboratory  1 

ATTN:  Code  910  (Robert  Paries) 

4555  Overtook  Avenue.  SW,  Room  2650 
Washington,  DC  20375 

Commander,  Navy  Center  for  Tactical  Systems 
Interoperabttty  (NTCSI)  1 

ATTN:  Code  5A  (Mr.  Pete  Whlby) 

200  Catalina  Boulevard 
San  Diego,  CA  92152-5082 

Director,  NCCOSC  ROTE  Division  1 

ATTN:  DN411  (Donna  Rshsr) 

49180  Transmtiter  Road,  Room  2 
San  Diego.  CA  92152-7341 

Commander.  NUSC  1 

ATTN:  Code  2222  (Richard  Leary) 

Bu  Being  1171-3 
Newport,  Rl  02841 

Office  of  Naval  InteNgence  1 

ATTN:  ONI-734  (Ms.  Joyce  Wineiand) 

4600  SfcerHB  Road 
Washington,  DC  20389-5000 

Office  of  Naval  Technology  1 

ATTN:  Code  221  (Sherman  Gee) 

Balaton  Center  Towers  1.  Room  503 
800  North  Quincy  Street 
Arlington.  VA  22217-5000 

Deputy  Chief  of  Staff  for  Programs  and  Resouteee  1 
US  Marine  Corps 
Cods  R 

Navy  Annex,  Room  3020 
Washington,  DC  20380 

Assistant  Chief  of  Staff,  C4I  Department,  US  Marine 
Corps  1 

ATTN:  Code  C4I  (Mr.  Ron  EBott) 

Federal  BuHdtog  2  (Navy  Annex),  Room  3234 
Washington,  DC  20380-1775 
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Assistant  Chief  of  Staff,  C4)  Department.  US  Marina 
Corps  1 

C4I  Architecture  &  Standards  Branch 
ATTN:  Coda  CSA  (UCol  J.  0.  Inghram.  Haad)) 
FadsraJ  Building  2  (Navy  Annax),  Room  3201 
Washington,  DC  20380-0001 

Assistant  Chiaf  of  Staff,  C4I  Dapartmant,  US  Marina 
Corps  1 

C4I  Systems  Branch 

ATTN:  Coda  CS8  (Col  J.  E.  Vsssiy,  Haad) 

Fadatal  Suiting  2  (Navy  Annax),  Room  331 2 
Washington,  DC  20380-0001 

Commandar,  Marina  Corps  Syatama  Command  2 

ATTN:  DirsctorC4l  (Coi  S.  J.  Dlugoa.  Mr.  Dan 
Waish) 

2033  Barnett  Avanua 
Marina  Corps  Baas 
Quantico.  VA  22134*5010 

Commandar,  Marina  Corps  Syatama  Command  2 

Director  C4I,  C4I  Interoperability  and  Intagration 
ATTN:  C4I2&I 

2033  Bamatt  Avanua,  Suita  31S 
Marina  Corps  Baas 
Quantico.  VA  22134-5010 

Commandtog  General,  Marina  Corps  Combat 

Development  Command  1 

ATTN:  Raquiramonta  Division  (Maj  Imhof) 

Matins  Corps  Bass 
Quantico.  VA  22134 

Director,  MGOTEA  1 

ATTN:  ACTB  (Maj  Michael  Maacaranas) 

3035  Bamatt  Avanua 
Marina  Corps  Bass 
Quantico.  VA  22134-5014 

Director,  Marina  Corps  Computers  and 

Telecommunications  Activity  (MCCTA)  1 

ATTN:  CTAS 
Marino  Corps  Bass 
Quantico.  VA  22134-5080 

Director,  Marina  Corps  Computers  and 

Telecommunications  Activity  (MCCTA)  1 

ATTN:  Technical  Director  (Mr.  Antonich) 

Marina  Corps  Base 
Quantico.  VA  22134-6080 

Commandar,  Marine  Corps  Tactical  Systems  Support 
Activity  (MCTSSA)  1 

ATTN:  Col  Chadwick,  Commander  Mr.  Jm 

QfAAfMMMlK 

oivvnwvmi 

Camp  Psndtoton.  CA  82065-6080 

Department  pf  the  Mr  Foret 

HQUSAF,  DCSC4  1 

ATTN:  AF/SCTA  (MAJ  M*e  Pair) 

The  Pentagon,  Room  5B613 
Washington,  DC  20330-1250 


HQUSAF,  DCS  C4 

ATTN:  AF/SCTA  (Mr.  Fred  Virtue) 

The  Pentagon,  Room  5B513 
Washington.  DC  20330-6190 

HQUSAF.  DCS  C4 
Directorate  of  Mission  Systems 
ATTN:  AF/SCM  (Coi  Joseph  M.  Narsavage) 
The  Pentagon,  Room  58525 
Washington,  DC  20330 

HQUSAF,  DCS  C4 

Directorate  of  Plans  and  Polcy,  Poky  Division 
ATTN:  AF/SCXX  (UCol  Larry  Cannon) 

The  Pentagon,  Room  5B315 
Washington,  DC  20330-6190 

HQ  USAF,  DCS  Piano  and  Operations 
Directorate  of  Forces,  Combat  Integration  Div. 
ATTN:  AF/XOFI  (Col  R.  Starwrtsr) 

The  Pentagon,  Room  4C174 
Washington,  DC  20330 

HQUSAF 

Directorate  of  Operational  Requirements 
ATTN:  AF/XOR  (Coi  M.  Ward,  Deputy  Director) 
The  Pentagon,  Room  4E1021 
Washington.  DC  20330-6190 

HQ  USAF,  Air  Force  intstigsnee  Agency 
ATTN:  AFISA/IND  (Maj  Mark  Harris) 

520  Boting  Air  Force  Baas 
Washington,  DC  20332 

HQUSAF 

ATTN:  SC/XPT  (Me.  Szabeth  Crouse) 

Gunter  Air  FOtce  Base,  AL  82225-8001 

HQ  USAF  Electronic  Systems  Command 
ATTN:  ESC/AVB 
9EgRn  Street 

Hanacom  Air  Force  Baas,  MA  01731-2110 

HQ  USAF  Air  Combat  Command 
ATTN:  AOCORt-SD  (Maj  Thomas  Spivey) 

204  Dodd  Boulevard,  Su8e  228 
Langley  Air  Force  Base,  VA  23886-2777 

HQ  USAF  Air  Combat  Command 
ATTN:  AOQORC 
204  Dodd  Boulevard.  Suita  202 
Langlsy  Air  Foma  Base,  VA  23865-2777 

HQ  USAF  Air  Combat  Command 
ATTN:  ACOSCT 
180  Denedtet  Avenue,  Suite  206 
Langley  Air  Force  Baas,  VA  23885-1983 

HQ  USAF  Spaoe  Command 
ATTN:  SYE  (Capt  Cosgrove) 

Peterson  Air  Force  Base,  CO  80194-6001 

HQ  USAF  Spaoe  Command  ^ _ 

North  American  Air  Defense  Command 
ATTN:  94 

150  Bandanberg  Street,  Suite  1106 
Peterson  Air  Force  Baas,  CO  80194-4080 
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CIA  Central  Intelligence  Agency 


initiative) 

ONC  Coammder-m-Chief 

ONCHAN  Allied  Coamundar-in-ChiefChaniel 
CIPSO  Common  IP  Security  Option;  Commercial 
Intenet  Protocol  Security  Option 
CIS  Communications  and  Information  System 

(NATO);  CASE  Integration  Services 
(committee);  Command,  Control, 
finnmnniniiiniK,  god  information  Systems 
(UK) 

CISPR  International  Special  Committee  an  Radio 

Interference 


CMS  Command  Management  System  (US  Army); 

Common  Mapping  Standard;  Communication 
Management  System  (Canada) 

Carnegie  Mellon  University 
Compartmented  Mode  Workstation 
Counter  Narcotics 

Conference  of  National  Armaments  Directors 
(North  Atlantic  Council,  NATO) 

Combat  Net  Radio 
Communication  System/Network 
Interoperability 

Connection  Oriented  (mode);  Change  Over 
(systems  management  function) 

Course  of  Action;  Central  Operating 
Authority  (NATO) 

COCMSF  Common  OSI  Connection  Management 
and  Support  Functions  (IEEE) 

CODAS  YL  Conference  on  Data  Systems  Languages 
COE  Common  Operating  Environment 

COEC  Council  Operations  and  Exercise  Committee 

(NACinNATO) 

COLDCMWG  Character-Oriented  Language 

Development  and  Configuration  Management 
Working  Group  (ADSIA) 

COLOC  Change  of  Location  of  Command 
Com  ms  Communications 


CMU 
CMW 
CN 

CICS  Customer  Information  Control  System  (IBM)  CNAD 

ODR  Classless  Interdomain  Routing 

C3EG  Common  Information  Exchange  Glossary  CNR 

CIGOS  Canadian  Interest  Group  on  Open  Systems  CNSI 

CK3REF  Chib  Infionnatique  des  Grandes  Enterprises 

Frsncaises  (Ranee)  CO 

CIM  Center  for  Information  Management  (PISA); 

Corporate  Information  Management  (US  DoD  COA 


OTIS 

CL 

CU 

nm 

CLIP 

CLIPCM 

CLNP 

CLNS 

CLTP 

CLTS 

CM 

CM-IS 


CMA 

CMB 

CMC 

CMD 

CMF 

CMI 

ChllP 

CMIS 

CMisyp 

CMMS 


Contractor  Integrated  Technical  Information 
Service 

Connectionless  (mode) 

Call  Level  Interface  (SQL) 

Common  I  anguage-Independcnt  Data  Types 
Common  Language-Independent  Roceduie 
Calling  Mechanisms 

Common  Language-Independent  Procedure 
Catling  Mechanisms 

Connectionless-mode  Network  Protocol  (OSI) 
Cotmectioniess-mode  Network  Service  (OSI) 
Connectionless-mode  Transport  Protocol 
(OSD 

Connectionless-inode  Transport  Service  (OSD 
Configuration  Management 
Connection  Mmagrmcnt  Interface 
Specification 

Configuration  Management  Authority 
Configuration  Management  Board 
(STAMINA) 

Common  Mail  Calls  (XAPIA) 

Color  Monitor  Device 
Common  Message  Format 
Communications  Interface  Profile  (ISQflEC 
TR 10000-1) 

Common  Management  Information  Protocol 

(OSD 


COMPUSEC  Computer  Security 
COMSEC  Communications  Security 
CONOPS  Continuity  of  Operations 
CONP  Comection-Oriemed  Network  Protocol  (OSD 

CONS  Connection-Oriented  Network  Service  (OSD 

CONUS  Continental  United  States 
CORBA  Common  Object  Request  Broker  Architecture 
(OMG) 

COS  Corporation  far  Open  Systems  International 

COSAC  Canadian  Open  Systems  Application  Criteria 
COSC  Coordinating  Operational  System  Control 

(ZODIAC,  The  Netherlands) 

COSE  Common  Open  (Operating)  Software 

Environment 

COSINE  Corporation  for  Open  Systems 

Interconnection  Networking  in  Europe 
(COSINE) 

COTS  Connection-Oriented  Transport  Service  (OSI); 

Commercial  Off-the-Sbelf 
CP  Command  Post;  Change  Proposal 

CPCN  Command  Post  Communication  Network 

CPI-C  X/Open  Common  Programming  Interface- 

Communications 

CR  Central  Region  (NATO) 

CRC  Cyclic  Redundancy  Check 

CRT  Cathode  Ray  Tube 

CS  Command  Sequencer  (systems  management 

function);  Convergence  (sublayer  of  ATM) 


(OSD 

Common  Management  Information  Services 
and  Protocols 

Cryptographic  Material  Management  System 

(Cauda) 


CSA 

CSDN 

CSG 

CSL 

CSL 


Ontarian  Standards  Association 
Circuit  Switched  Data  Network 
Computer  Scene  Generation 
Computer  Systems  Laboratory  (NIST) 
CALS  SGML  Library  (US  DoD) 
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CSMA  Carrier  Sense  Multiple  Access 
CSMA/CD  Carrier  Sense  Multiple  Access/Collision 
Detection 

CSMF  Conceptual  Schema  Modelling  Facility 
CSN  Circuit  Switched  Network 

CSNI  Communications  System/Network 

Interoperability 

CSP  Communicating  Sequential  Processes 

(LOTOS) 

CSPDN  Circuit  Switched  Public  Data  Network 
CSS  Combat  Service  Support;  Communications 

Support  System  (US  Navy) 

CSSCS  Combat  Service  Support  Control  System 
(US  Army) 

CSWG  Communications  Systems  Working  Group 
(NAOSC.WG1) 

CTAPS  Contingency  Tactical  Air  Control  System 

(TACS)  Automated  Planning  System  (US 
Air  Force) 

CTIM  CASE  Tool  Integration  Models  (ANSI) 

CTIS  Combat  Terrain  Information  System  (US 

Army) 

CTMF  Conformance  Testing  Methodology  and 

Framework 

CTS  Conformance  Testing  Services 

(CEN/CENELEC) 

CTS-WAN  Conformance  Testing  Services-Wide  Area 
Network 

CUA  Common  User  Access  (IBM) 

CULR  Common  Upper  Layer  Requirement 

CVSD  Continuously  Variable  Slope  Delta  (voice 

transmission  modulation) 

D  ISDN  D  Service  (16  kbit/second);  Document 

DA  Danish  Army;  US  Department  of  the  Army 

DAA  Data  Authentication  Algorithm  (FIPS  1 13) 

D AC  Discretionary  Access  Control 

DAD  Draft  Addendum  (ISO) 

DAF  Framework  for  the  Support  of  Distributed 

Applications  (OCTIT);  Distributed 
Applications  Framework  (OSF) 

DAFTG  Database  Architecture  Framework  Task  Group 
(ANSI) 

DAI  Distributed  Artificial  Intelligence 

DAM  Draft  Amendment  (ISO) 


DCE  Data  Circuit-Terminating  Equipment 

(CCITT);  Distributed  Computing 
Environment  (OSF) 

DCF  Data  Communication  Function 

DCM  Distributed  Computing  Model  (Bull) 

DC  PS  Data  Communications  Protocol  Standards 

(USDoD) 

DCS  Defense  Communications  System 

DCT  Digital  Communications  Terminal  (US  DoD) 

DCW  Digital  Chart  of  the  World 

DDL  Data  Definition  Language 

DDN  Defense  Data  Network  (US  DoD)  (now 

DISN) 

DEA  Drug  Enforcement  Agency  (US) 

DEC  Digital  Equipment  Corporation 

DEFSTAN  Defence  Standard  (UK  MOD) 

DEOS  Danish  EUROCOM  Communication  System 
DER  Distinguished  Encoding  Rules  (ASN.l) 

[(replaced  by  Canonical  Encoding  Rules 
(CER)] 

DFAD  Digital  Feature  Analysis  Data 

DFR  Document  Filing  and  Retrieval 

DFS  Distributed  File  System 

DFTS  Defence  Fixed  Telecommunications  System 

(UK) 

DGIWG  Digital  Geographic  Information  Working 

Group 

DGTTS  Directorate  of  Information  Technology 

Systems  (UK  MOD) 

DGSA  DoD  Goal  Security  Architecture  (formerly 

DLSSP  Goal  Security  Architecture) 

OA  Defense  Intelligence  Agency 

DIB  Directory  Information  Base 

DID  Data  Item  Descriptors 

DIGEST  Digital  Geographic  Information  Exchange 
Standard 

DO  Defense  Information  Infrastructure  (US) 

EMN  Deutsches  Institut  fur  Normimg  (Federal 

Republic  of  Germany) 

DIR  Directory 

DIS  Draft  International  Standard  (ISO);  Distributed 

Interactive  Simulation  (IEEE  1278) 

DIS  A  Defense  Information  Systems  Agency  (US 

DoD,  formerly  DCA);  Data  Interchange 
Standards  Association 


DAO  Document  Architecture  Operations  DISN  Defense  Information  System  Network 

DAP  Document  Application  Profile  DIS  NET  Defense  Integrated  Secure  Networic  (US  DoD) 

DAPWG  DFTS  Architecture  and  Procurement  Working  DISP  Draft  International  Standardized  Profile 

Group  (UK)  DISSP  Defense- Wide  Information  Systems  Security 

DARPA  Defense  Advanced  Research  Projects  Agency  Program 

(US  DoD)  DIT  Directory  Information  Tree 

DB  Database  DK  Denmak 

DBE  Database  Enquiry  (EWOS)  DLCP  Data  Link  Change  Proposal  (NATO) 

DBMS  Database  Management  System  DLPI  Data  Link  Protocol  Interfere 


DCA  Defense  Communications  Agency  (see  DBA)  DLWG  Data  Lit*  Working  Group  (ADSIA) 

DCC  Data  Cotmtry  Code  DMA  Defense  Mapping  Agency  (US  DoD) 

DCCP  Defence  Communications  Corporate  Plan  DME  Distributed  Management  Environment  (OSF) 

(Australia)  DMF  Data  Modelling  Facility;  Data  Management 

Facility  (ATCCIS) 
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DMI  PMfaop  Mwnfmmi  TnUTfry  (DMTF) 

DML  Data  Martipulaiicn  language 

MIRM  Data  Management  Reference  Model  (SG12) 
DM S  Data  Management  Subsystem  (ACE  CCISs); 

Defame  Mange  System  (US  DoD) 

DMS  Defame  Message  System  (US  DoD) 

DMTF  Desktop  Management  Task  Force 

DNI  Detailed  Network  Interface  (IEEE);  Detailed 

Network  Interface 

DNS  Domain  Name  System  (US  DoD) 

DNSIX  DoD  OS  Network  Security  for  Information 

Exchange 

DOA  Distributed  Office  Application 

DO  AM  Distributed  Office  Applications  Model 

Doc  Document 

DoD  Department  of  Defense  (United  States) 

DoD-STD  DoD  Standard 
DoDCSC  US  Department  of  Defense  Computer 
Security  Center 

DODOS  DoD  Intelligence  Information  Systems 

DoDISS  DoD  Index  of  Standards  and  Specifications 

Do)  Department  of  Justice  (US) 

DOP  Directory  Operational  Bintfing  Management 

Protocol 

DORIC  Defence  Organization  Integrated 

Communications  (Australia) 

DoS  Department  of  State  (US) 

DOTS  DGSA  Overall  Transition  Strategy 

DP  Draft  Proposal  (ISO) 

DPA  Document  Printing  Application 

DPC  Defence  Pinning  Committee  (NATO) 

DPS  Digital  Production  System  (DMA) 

DPSN  Defence  Packet  Switched  Network  (UK) 

DQDB  Distributed  Queue  Dual  Bus  (local  area 

network) 

DQSO  Defense  Quality  Standardization  Office 

DRA  Defence  Research  Agency  (UK  MOD) 

DRDA  Distributed  Relational  Database  Architecture 

(IBM) 

DRG  Defense  Research  Group 

DS  Directory  Services 

DSA  Directory  System  Agent  (OSI) 

DSC  Distributed  System  Gateway 

DSNET  Defense  Secure  Network  (US) 

DSOM  Distributed  System  Object  Model 

DSP  Domain  Specific  Put;  Defense 

Standardization  Program  (US);  Defense 
Standanfeed  Profile  (US) 

DSS  Digital  Signature  Standard 

DSSSL  Document  Style  Segmentation  and 

Specification  Language 
DST  Decision  Support  Tool 

DTAM  Document  Transfer  and  Manipulation 

DTD  Document  Type  Definition 

DTE  Data  Terminal  Equipment 

DTBD  Digital  Terrain  Elevation  Data 

DTMP  DO’S  Technical  Management  Panel  (US 

DoD) 


DTP  Distributed  Thnsarrion  Processing 

DTR  Draft  Technical  Report  (ISO) 

DTSS  Digital  Topographic  Support  System  (US 
Army;  see  CTIS) 

DUA  Directory  User  Agent  (OSI) 

DVI  Digital  Video  Interactive 

E-Mail  Electronic  Mail 

E3  End-to-End  Encryption 

EA  Evolutionary  Acquisition 

EAC  Echelons  Above  Corps 

EBC  Evolutionary  BICES  Capability 

EC  European  Community 

ECB  Echelons  at  Corps  and  Below 

ECCF  Ifahanced  Communications  Functions  and 

Facilities 

ECCM  Electronic  County-Countermeasures 

ECE  Economic  Commission  of  Europe  (UN) 

ECFF  Enhanced  Cnmmnmauinns  Functions  and 

Facilities 

ECTTC  European  Committee  for  IT  Testing  and 

Certification 

ECMA  European  Computer  Manufacturers 

Assodation 

ECSA  Exchange  Carriers  Standards  Association.  Inc. 

ED&C  Error  Detection  and  Correction 

EDI  Electronic  Data  Interchange 

EDIFACT  Western  European  Electronic  Data 

Interchange  fra  Administration,  Commerce, 
and  Transportation 

EDOM  Electronic  Data  Interchange  Messaging 

RKt  Bitnwial  FnimnmHV  inlwfeffM 

EES  Enhanced  EUROCCAf  Standard 

EESP  End-to-End  Security  Protocol 

EFTA  European  Free  Trading  Association 

EG  Expert  Groups  (NIST  OSI  Implementor's 

Workshop) 

BGDBE  Expert  Group  on  Database  Enquiry 

EGDIR  Directory  Expert  Group  (EWOS) 

EGTP  Expert  Group  on  Transaction  Processing 

(EWOS) 

EIA  Electronic  Industries  Association 

EIA/EPC  Engineering  Policy  Council 

EIFEL  Allied  Tactical  Operations  Centre  OCIS 

(ATOC  COS,  also  known  as  the  EIFEL 
Follow-On) 

ELINT  Electronic  Intelligence 

EMD  Engineering  and  Manufacturing  Development 

EMPM  Electronic  Manuscript  Preparation  and 

Markup 

EMUG  European  Manufacturing  Automation 

Program  (MAP)  User  Group 
EN  European  Norm  (European  Standard) 

(CEN/CENELBC) 

ENSCE  Enemy  Situation  Correlation  Element 

European  Norm  Votnotm  (European 
Experimental  Standard)  (CEN/CENELBC) 
Environmental  Protection  Agency  (US 
Government) 


EPA 
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EPHOS  European  Procurement  Handbook  for  Open 
Systems  (CEC) 

EPLRS  Enhanced  Position  Location  Reporting 
System 

EPRI  Electric  Power  Research  Institute 

ERA  Entity-Relation- Attribute 

ES-IS  End  System  to  Intermediate  System 

ESC  Electronic  Systems  Center  (US  Air  Force) 

ESF  Eureka  Software  Factory 

ESO  External  Security  Object  (ISO) 

ESPRIT  European  Strategic  Programme  of  Research 

and  Development  in  Information  Technology 
ESQL  Embedded  SQL 

ESRA  Engagement  Scheduling  and  Recording 

Application 

ETC  EWOS  Technical  Guide 

ETS  European  Telecommunications  Standard 

(CEC) 

ETSI  European  Telecommunications  Standards 

Institute 

EIUF  European  ISDN  Users  Forum 

EUROCOM  EUROGROUP  on  Cooperation  of 
Tactical  Communications  Systems 
EUTELSAT  European  Telecommunications  Satellite 
Organization 

EV  Event  (systems  management  function) 

EVS  Event  Service  (OSFs  DME) 

EWOS  European  Workshop  for  Open  Systems 

EWSA  Exponentially  Weighted  Stochastic 

Approximation 

F  interchange  formal  and  representation  profile 

class 

FAAD  Forward  Area  Air  Defense 

FACC  Feature  Attribute  Coding  Catalog 

FAIS  Factory  Automation  Interconnection  System 

FAS  Forward  Area  System 

FC  Facilities  Control  (ZODIAC,  The 

Netherlands);  Federal  Criteria  (US) 

FCG  Format-Computer  Graphics  (profile) 

FCS  Frame  Check  Sequence;  Fast  Connection 

Setup 

FD  Formal  Description 

FDDI  Fiber  Distributed  Data  Interface 

FDDI-LCF-PMD  Fiber  Distributed  Data 

Interface  -  Low  Co6t  Fiber  -  Physical  Layer 
Medium  Dependent 

FEICO  forms  field  entry  instruction  control  object 

FEPCO  forms  field  entry  pilot  control  object 

FDI  Format-Directory  (Data  Definitions  profile) 

FDT  Formal  Description  Technique 

FEC  Forward  Error  Correction 

FEDISEE  Federation  of  Integrated  Software  Engineering 
Laboratories  (NIST) 

FFM  Forschungsinstitut  fiir  Funk  und  Mathcmatik 

(Germany) 

FFOL  FDDI  Follow-On  LAN 

FFOL-AMAC  FFOL  -  Asynchronous  Media  Access 
Control 


FFOL-IMAC  FFOL  -  Isochronous  Media  Access 
Control 

FFOL-PHY  FFOL  -  Physical  Layer  Protocol 
FFOL-PMD  FFOL  -  Physical  Medium  Dependent 
FFOL-SMT  FFOL  -  Station  Management 
FFOL-SMUX  FFOL  -  Service  Multiplexer 
FIMS  Forms  Interface  Management  System 

FIPS  Federal  Information  Processing  Standard 

(United  States) 

FIRP  Federal  Internetworking  Requirements  Panel 

(US) 

FLTSATCOM  Fleet  Satellite  Communications 
FM  Faroe  Management  (ACCS) 

FMBS  Frame-Mode  Bearer  Service  (ISDN) 

FMCT  Formal  Methods  in  Conformance  Testing 

FMS  Fixed/Mobile  Segment 

FNC  Federal  Networking  Council  (US) 

POD  Format-Open  Document  (profile) 

FOIRL  Fiber  Optic  Inter-Repeater  Link 

FORMETS  Message  Text  Formatting  System  (NATO) 
FORTRAN  Formula  Translation  (programming 
language) 

FRP90  Frigate  Replacement  Program  for  the  1990s 

(NATO) 

FSDWG  Functional  Segment  Development  Working 

Group  (ADSIA) 

FSG  Fonnat-SGML  (Interchange  profile) 

FSK  Frequency  Shift  Keying 

FSN  Final  Sequence  Number 

FSSG  Fire  Support  Subgroup  (JTC3A) 

FT  AM  File  Transfer,  Access  and  Management  (OSI 

Layer  7) 

FTP  Hie  Transfer  Protocol  (US  DoD) 

FTR  Future  (standard) 

FUI  Flow  (Control)  Unnumbered  Information 

FVT  Format- Virtual  Terminal  (Registered  Object 

profile) 

FWUF  Federal  Wireless  Users  Forum  (US) 

G-LOTOS  Graphical  LOTOS  (profiles) 

GAG-R  GOSIP  Advisory  Group  on  Registration  (US) 

GAN  Global  Area  Network 

GAP  stop-gap  (mo-strategic  standard) 

GASS  Generic  Abstract  Services  for  Security 

Gbps  gigabits  pa  second 

Gbytes  Billions  (thousand  millions)  of  bytes 

GCCS  Global  Command  and  Control  System  (US) 

GDM1  Generic  Definition  of  Management 

Information  (OSD 

GDMO  Guidelines  for  the  Definition  of  Managed 

Objects 

GFADGE  German  Air  Defense  Ground  Environment 

GEX  Group  of  Experts 

GHz  Gigahertz 

GIF  Graphics  Interchange  Format 

GIS  Geographic  Information  System 

GK  Graphic  Shelters  (HEROS,  Germany) 

GKS  Graphical  Kernel  System 
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GKS-3D 

Graphical  Kernel  System  for  Three 

1CA 

Integrated  Communications  Architecture 

Dimensions 

ICAM 

Integrated  Computer-Aided  Manufacturing 

GLOBIXS  Global  Information  Exchange  Systems 

ICASE 

Integrated  Computer-Aided  Software 

GMI 

Generic  Management  Information 

Engineering  (See  ISEE) 

GNMP 

Govcnuncnt  Network  Management  Profile 

ICC  CM 

Inter-Client  Communications  Conventions 

GOSI 

Generic  Operating  System  Interface 

Manual 

GOSIP 

Government  Open  Systems  Interconnection 

ICD 

International  Code  Designator 

Profile 

ICL 

International  Computers  Timing 

GOTS 

Government  Off-tfae-Sbelf 

ICP 

Infrastructure  Capability  Packages 

GPEF 

Generic  Package  of  Elementary  Functions 

ICS 

Implementation  Conformance  Statement 

GPPF 

Generic  Package  of  Primitive  Functions 

ICSI 

International  Coding  System  Identifier 

GRD 

GOSIP  Register  Database 

ICT 

Intercept  Recommendation  (TSGCE  SG9) 

GSM 

Group  Special  Mobile  (The  Netherlands  car 

ID 

Identification 

telephone  network) 

IDA 

Institute  for  Defense  Analyses 

GSTN 

General  Switched  Telephone  Network 

ID  API 

Independent  Database  API  (Borland 

GTDF 

Generic  Transformed  Database  Format 

International,  IBM,  and  Novell) 

GTDI 

EDI  Standard  (syntax) 

idb 

Integrated  Data  Base  (MODS) 

CM 

Graphical  User  Interface 

EDBEF 

Integrated  Database  Extract  Format 

GULS 

Generic  Upper  Layer  Security 

IDBTF 

IDC 

Integrated  Database  Transaction  Format 
International  Data  Corporation 

HQ 

Human-Computer  Interface 

IDEF 

Integrated  Computer-Aided  Manufacturing 

HD 

Harmonized  Document  (CEN/CENELEC) 

(ICAM)  Definition  (Language) 

HD-DOMS  HyperDesk  Corporation's  Distributed 

EDEFO 

IDEF  Activity  Modeling  (Language) 

Object  Management  System 

IDEF1X 

IDEF  Data  Modeling  (Language)  Extended 

HDDI 

High  Definition  Digital  Interface 

IEH 

Initial  Domain  Identifier 

HDLC 

High-Level  Data  Link  Control  (OSI  Layer  2) 

idl 

Interface  Definition  Language 

HDTV 

High  Definition  Television 

IDMR 

Inter-Domain  Multicast  Routing  (Internet) 

HDU 

Hard  Disk  Unit 

IDN 

Interface  Definition  Notation  (ECMA 127) 

HEROS 

Heeres-Fuehrungsinfonnatioossystem  fur  die 

IDP 

Initial  Domain  Part 

rechnergestuetzte  Operations-  fuehrung  in 

EDR 

Information  Distribution  and  Receipt 

Staeben 

fi>RP 

Inter-Domain  Routing  Protocol 

HF 

High  Frequency 

IEC 

International  Electrotechnical  Commission 

HFS 

Human  Factors  Society 

IFF 

Institution  of  Electrical  Engineers  (United 

HIDS 

Headquarters  Information  Distribution  System 

Kingdom) 

(Canada) 

IFRF 

Institute  of  Electrical  and  Electronics 

HIS 

Headquarters  Information  System 

Engineers  (United  States) 

HP 

Hewlett-Packard 

IEG 

Information  Exchange  Group  (NATO) 

HQ 

Headquarters 

EEPG 

Independent  European  Programme  Group 

HQADF 

Headquarters  Australian  Defence  Force 

(NATO) 

HTU 

Handheld  Terminal  Unit 

EER 

Information  Exchange  Requirement 

HUI 

Human  Interface 

IETF 

Internet  Engineering  Task  Force 

HW 

Hardware 

IETM 

Interactive  Electronic  Technical  Manual  (US 

HYTIME  Hypennedia/Tune-based  Structuring  Language 

IEW 

DoD) 

Intelligence  and  Electronic  Warfare 

I/F 

Interface 

IFF 

Interchange  Tile  Format 

1AB 

Internet  Architecture  Board  (US  DoD) 

IFIP 

International  Federation  for  Information 

IAB/EETF  Internet  Architecture  Board/Intemet 

Processing 

Engineering  Task  Force 

EFRB 

International  Frequency  Registration  Board 

IACSS 

International  Association  for  Computer 

(UTD 

Systems  Security 

IFSAS 

Interim  Fire  Support  Automation  System 

IAeG 

Inter-Agency  edi  Working  Group 

(US  Army) 

IAL 

International  Access  Link  (The  Netherlands) 

IFU 

Interworking  Functional  Unit 

IAP 

Interfaces  for  Applications  Portability 

IGES 

Initial  Graphics  Exchange  Specification 

(ISGfiECJTCl) 

IGOSS 

Industry  Government  Open  System 

IARRCIS  Interim  ACE  Rapid  Reaction  Corps 
Information  System  (UK,  ACE) 

IHO 

Specification 

International  Hydrographic  Organization 

IBM 

International  Business  Machines 

nc 

International  Institute  of  Communications 

IBN 

Institut  Beige  de  Normalisation  (Belgium) 

HF 

Image  Interchange  Facility 
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HRS  Institute  for  Industrial  Research  and  Standards 
(Ireland) 

IIS  Intelligencelnfonnation  System 

OW  ISDN  Implementor's  Workshop 

UMS  Interim  JTIDS  Message  Specification 

KBS  Integrated  Knowledge-Based  System 

ELS  Integrated  Logistics  Support 

IMA  Information  Mission  Area 

IMAC  Isochronous  Media  Access  Control  (FDDI, 
FFOL) 

IMETS  Integrated  Meteorological  System  (US  Army) 
IMIL  Library 

IMS  International  Military  Staff  (NATO  HQ) 

IMSC  Imagery  Standards  Management  Committee 

(USDoD) 

INFOSEC  Information  Security 
INSTAC  Information  Technology  Standardization 
Technology  Committee 

INTAP  Interoperability  Technology  Association  for 
Information  Processing  (Japan) 

INTELSAT  International  Telecommunications  Satellite 
Organization 

INTEROP  International  Operations 
INTSUM  Intelligence  Summary 
INTUG  International  Telecommunications  Users 
Group 

INTWP  Intelligence  Interservice  Working  Party  (MAS 
Army  Board,  NATO) 

INX  Information  Exchange 

IOC  Initial  Operational  Capability 

IOF  Input-Output  Facility  (ATCCIS) 

IONL  Internal  Organization  of  the  Network  Layer 

IOT&E  Initial  Operational  Test  and  Evaluation 

IP  Internet  Protocol;  Interoperability  Parameter, 

Internetwork  Protocol 

IPI  Image  Processing  and  Interchange 

IPM  Interpersonal  Messaging  (MHS  Service) 

IPMS  Interpersonal  Messaging  Service  (MHS) 

IP:ng  Next  Generation  Internet  Protocol 

IPO  IGES/PDES  Organization  (NIST) 

I  PS  EC  Internet  Protocol  Security  Protocol 

IPX  Internet  Packet  Exchange 

IR  International  Registry 

IRD  Information  Resource  Dictionary 

IRDS  Information  Resource  Dictionary  System 

IRIWP  Imagery  Reconnaissance  and  Interpretation 
Working  Party  (MAS  Air  Board,  NATO) 

IS  International  Standard  (ISO);  Intermediate 

System  (OS I);  International  Staff  (NATO 
HQ) 

IS-IS  Intermediate  System  to  Intermediate  System 

Routing  Protocol 

ISA  Integrated  Systems  Architecture 

ISAM  Indexed  Sequential  Access  Method 

ISCS  Integrated  Satellite  Control  Services 

ISDN  Integrated  Services  Digital  Network 

ISDN-BW  ISDN  for  the  German  Armed  Forces 
ISDN/NUF  ISDN  Network  Users  Forum 


ISEE  Integrated  Software  Engineering  Environment 

(ISEE)  Working  Group  (NIST) 

ISI  Information  Storage  Interface  Profile 

ISME  International  Subject  Matter  Expert 

ISO  International  Organization  far  Standardization; 

International  Standard 

ISO-DCC  International  Organization  for  Standardization; 

International  Standard-Data  Country  Code 
ISO-SWG  International  Organization  for 

Standardization;  International  Standard-Special 
Working  Group 
ISOC  Internet  Society 

ISOM  ISO  Development  Environment 

ISP  International  Standardized  Profile 

ISPABX  Integrated  Services  Public  Acoess  Branch 

Exchange 

1ST  International  Standards 

ISUP  ISDN  Signalling  System  No.  7  User  Pat 

ISWG  Information  Systems  Working  Group 

(NACISC  WG2) 

IT  Italy;  Information  Technology 

ITD  Interim  Terrain  Data 

ITDN  Integrated  Tactical-Strategic  Digital  Network 

(USDoD) 

ITF  Information  Transfer  Format 

m  Industrial  Technology  Institute 

ITPB  Information  Technology  Policy  Board 

ITRC  Information  Technology  Requirements 

Council 

ITS  Integrated  Tool  Set  (COS) 

1TSB  Infonnation  Technology  Standards  Board  (UK 

MOD) 

ITSDN  Integrated  Tactical  Strategic  Digital  Network 

(USDoD) 

1TSEC  Infonnation  Technology  Security  Evaluation 

Criteria 

ITSG-OSE  Information  Technology  Standards 

Guidance  for  an  Open  System  Environment 
(TAFIM,  USDoD) 

ITSTC  Information  Technology  Steering  Technical 

Committee  (UK) 

ITU  International  Telecommunications  Union 

ITU-TS  International  Telecommunication  Union  - 

Telecommunication  Standardization  Sector 
(formerly  CCITT) 

ITU-TSB  International  Telecommunications  Union  - 

Telecommunications  Bureau  (formerly 
CCITT) 

IUKADGE  Improved  United  Kingdom  Air  Defence 
Ground  Environment 
IUT  Implementation  under  Test 

IUW  ISDN  User’s  Workshop 

IVD  Integrated  Voice  and  Data  (local  area  network) 

IWF  Interworking  Function 

IWG  Information  Working  Group 

IWU  Interworking  Unit  (OSI  far  relay  functional 

profiles) 
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J6I  US  Joint  Staff 

JANAP  Joint  Aimy,  Navy,  Air  Force  Pnblkation 

JASMIN  Joint  Analysis  System  Military  Intelligence 
(Germany  national  intelligence  system) 

JBIG  Joint  Bi-Level  Imaging  Group 

JCS  Joint  Chiefs  of  Staff 

J1NTACCS  Joint  Interoperability  of  Tactical  Command 
and  Control  Systems  (US  DoD) 

BBO  Joint  Interoperability  and  Engineering 

flrg—  iliariwi 

JIS  Japanese  Industrial  Standard 

JISC  Japanese  Industrial  Standards  Committee 

JITC  Joint  Interoperability  Test  Center  (US  DoD) 

JMCIS  Joint  Maritime  Command  and  Infonnatioo 
System  (US  Navy,  USPACOM) 

JMSWG  Joint  Messaged  Standards  Working  Group 
(JTC3A) 

JOPES  Joint  Opemtkns  Planning  and  Execution 

System 

JPEG  Joint  Photographic  Experts  Group 

JROC  Joint  Requirements  Oversiglit  Council  (US 

DoD) 

JSA  Japanese  Standards  Association 

JTAP  JTC1  TAG  Applications  Portability  Study 

Group 

JTC  Joint  Technical  Committee 

JTC1  Joint  Technical  Committee  One  (ISCVIEO 

JTC3A  Joint  Tactical  Omunand,  Control  and 

Communications  Agency 
JTF  Joint  Task  Force 

JHDS  Joint  Tactical  Infonnatioo  Distribution 

System 

JTM  Job  Transfer  and  Manipulation  (OSI  Layer  7) 

JTSSG  Joint  Technical  Standards  Steering  Group 
(DoD) 


LAPD  Link  Access  Procedure.  VeniooD  (used  for 

ISDN) 

LAS  Local  Area  (Access)  Subsystem 

lb  Pounds 

LCAS  Language  Compatible  Arithmetic  Standard 

LCF  Low-Cost  Fiber  (FDDD 

LCC  Limited  Capability  Configuration 

LDM  Logical  Data  Model 

LDN  Local  Distribution  Netwofc  (Canada) 

LEWWG  Land  Electronic  Warfare  Working  Group 

(NATO) 

LIS  Language  Independent  Specification  (IEEE 

POSDO 

LISA  Link  in  Support  of  ACCS 

LLC  Logical  Link  Control  (OSI  Network  Layer) 

LMS  License  Management  Service  (OSFsDME) 

LMX  Local  Area  Network  Manager 

LOC  Levels  of  Operational  Capability  (ACCS) 

LOCE  United  Operations-ImeHigence  Centers 

Europe;  Limited  OperatioiialCapability- 
Europe  (US  national  intelligence  system) 

LOD  Levels  of  Detail 

LOTOS  Language  of  Temporal  Ordering  of 

Specification 

LPI  Low  Probabifity  of  Intercept 

LRC  Logistic  Reporting  Conference  (NATO  MNC 

support  for  ACE) 

LRCS  Long-Range  Communications  System 

(Canada) 

LRM  Language  Reference  Model 

LTACFIRE  Lightweight  Tactical  Fire  Direction  System 

Ltd  Limbed 

LTDP  Long-Term  Defence  Ptau(ning) 

LVT  Low  Volume  Terminal 

LWER  Lightweight  Encoding  Rides 


KAPSE  Kernel  Ada  Programming  Support 

Environment 

KBS  Knowledge-Based  System 

kbytes  Thousands  of  bytes 

KDC  Key  Distribution  Center  (BLACKER) 

KDP  Key  Distribution  Protocol 

kHz  Kilohertz 

KEF  Knowledge  Interchange  Format 

JOT  KAPSE  Interface  Team 

KTFIA  KAPSE  Interface  Team  from  Industry  md 

Academia 

KMAE  Key  Management  Application  Entity 

KMAP  Key  Management  Application  Process 

KMASE  Key  Management  Application  Service 
Element 

K2U  Special  Signalling  Conveners  (Germany) 

LAAD  Low-Altitude  Air  Defense 

LACS  Local  Area  Communications  Subsystem  1 

Netherlands) 

LAN  Locd  Area  Network 

LAPB  Link  Access  Procedure,  Balanced 


MAC  Media  Access  Control 

MACF  Multiple  Association  Control  Fhnctioo 

MACH  OSF/1  Microkernel  Openting  System 
MAGTF  Marine  Air-Ground  Task  Force  (US  Marine 
Corps) 

MAN  Metropolitan  Area  Network 
MAP  Manufacturing  Automation  Protocol 
MAPI  Messaging  API  (Microsoft) 

MAPLE  Manufacturing  Automation  Frogremmiiig 
Language  Environment  Architecture 
MAPSE  Minimum  Ada  Programming  Support 
Environment 

MARREP  Maritime  Reporting  System  (NATO) 
MAS  Military  Agency  for  Stsndsrdization  (NATO 
Military  Committee) 

MBER  Minimum  Basic  Encoding  Rules  (ASN.l) 

Mbps  Megabits  per  second 
Mbytes  Millions  of  bytes 
MC  Military  Committee  (NATO);  Military 
Qwracteristic  (NATO  requirenient) 

MCAG  Mapping.  Charting,  and  Geodesy  (DMA) 
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MCCR  Mission  Critical  Computer  Resources  (US 
DoD) 

MCFSS  Marine  Corps  Fire  Support  System  (US) 
MCG  Mapping,  Charting,  and  Geodesy 
MCGT  Mapping,  Chatting  and  Geodesy  Technology 
Standardizatioo  Area  (US  DoD) 

MCS  Maneuver  Control  System  (US  Anny) 

MF  Mediatkn  Function 

MFS  Message  Formatting  System  (UK) 

MG  Multinational  Group  (NATO) 

Mgd  Managed 

Mgml  Management 
MH  Messager  Handler 

MHEG  Multimedia  and  Hypennedia  Infonnatioo 
Coding  Experts  Group 

MHS  Message  Handling  System  (OSI  Layer  7); 

Message  Handling  Service  (Novell,  Inc.) 
MHz  Megahertz 

MIA  Multivendor  Integration  Architecture 
MIB  Management  Infonnatioo  Base 

MIDLA  Media-Independent  Data  Link  Atchilecture 
(TSGCE) 

MIDS  Multifunctional  Information  Distribution 
System  (NATO) 

MIF  Management  Infannation  Hie 

MUDS  Military  InteUigcnce  Integrated  Data  System 

(US) 

MIL-STD  Military  Standard  (US  DoD) 

MILNET  Military  Netwotk  (United  Stales) 

MIM  (Netwotk)  Management  Information  Model 
(US  DoD) 

MIME  Multimedia  Internet  Mail  Extension 

MIPS  Management  Infonnatioo  Protocol 

Specification  (aee  CMff) 

MIR  Management  Information  Register 
MIS  Management  Information  Service  (OSI); 

Management  Information  Sysiem 
MISD  Management  Information  Service  Definition 
(reeCMIS) 

MIT  Massachusetts  Institute  of  Technology 


MOM  Message-Oriented  Middteware  Consortium 
MOR  Military  Operational  Requirement  (NATO) 
mOSI  Minimal  Open  Systems  Interconnection 
MOT  Means  of  Testing 

MOHS  Message-Oriented  Teat  Interchange  System 
(OSI  Layer  7) 

MOU  Memorandum  of  Understanding 
MPC  Multi-Party  Commnnicatians 
MPD  Multipeer  Data 

MPDT  Multipeer  Data  Transmission  (OSD 
MPEG  Moving  Picture  Expert  Group 
MPMC  Multipeer/Multicast  (MPDT) 

MPTM  Multi-party  Test  Methods 
MROC  Multicommand  Required  Operational 
Capability 

MRR  Multi-Role  Radio 

MS  Message  Store  (MHS);  Mobile  Subsystem; 
Microsoft 

MSC  Major  Subordinate  Command(cr]  (NATO) 
MS-DOS  Microsoft  Disk  Operating  Sysiem 
MSDSG  Multi-System  Distributed  Sysiem  Gateway 
MSE  Mobile  Subscriber  Element  (US  Army) 
MSF  Man-Machine  Support  Facility 
MSMV  Multipie  Sampling  and  Majority  Voting 
MSP  Message  Security  Protocol  (SDNS) 

MT  Message  Transfer,  Message  Terminal 

(ZODIAC,  The  Netheriuds) 

MTA  Message  Transfer  Agent  (MHS) 

MTACCS  Marine  Tactical  CammsDKl  and  Control 
System 

MTF  Message  Text  Format 
MTP  Message  Transfer  Part  (MHS) 

MTS  Message  Transfer  Sysiem  (The  Netfacrinfc); 

Marine  Tactical  Systems  (US  DoD) 

MTWP  Maritime  Tactical  Working  Party  (MAS 
Navy  Board,  NATO) 

MUS  Mobile  User  Subsystem 
MWWP  Mine  Warfare  Working  Party  (MAS  Navy 
Board,  NATO) 


MITI  Ministry  of  Interoarional  Trade  nd  Industry  n  Notice  (ISO  Working  Paper) 

(Japan)  NA  North  Americm 

MLP  Multi-Link  Procedure  (HDLC)  NAAG  NATO  Anny  Armaments  Group  (CNAD) 

MLS  Multi-Level  Secure  NAC  North  Atlantic  Coundl  (NATO) 

MM  Mixed  Mode  (of  Operations  in  DTAM)  NACISA  NATO  Communications  sod  Information 

MMHS  Military  Message  Handling  System  Systems  Agency  (NAOSQ 

MM1  Man-Machine  Interface  NACISC  rnmnwrir^ttnm  information 

MML  Man-Machine  Language  (CCITTZJOO  Systems  Committee 

Series)  NACISO  NATO  fV«Hni»ir— fan  and  Information 

MMS  Manufacturing  Mesaage  Specification  (MAP)  Systems  Organization 

MNC  Major  NATO  Command(er]  NACMA  NATO  ACCS  Management  Agency 

MND  Military  Need  Document  (NATO)  NACMO  NATO  ACCS  Management  Organization 

MO-.DCA  Mixed  Object  Document  Content  Architecture  NACSI  NATO  Advisory  Committee  for  Special 

MOA  Memorandan  of  Agreement  Intelligence  (NATO  Military  OommiUee) 

MOCS  Managed  Object  Conformance  Statement  NADC  NATO  Air  Defence  Commtoee 

MOD  Miniatry  of  Defence  (United  Kingdom)  NADDO  NATO  Desip  and  Development  Objective 

MODTTSB  Ministry  of  Defence  Infonnatioo  N AEGIS  NATO  AEWGtoiikI  Integration  Segment 

Technology  Standards  Board  (UK)  NAEW  NATO  Airborne  Eaiy  Warning 
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NAEWAC  NATO  Airborne  Early  Warning  and 
Control 

NAFAG  NATGO  Air  Force  Armaments  Group 
(CNAD) 

NAFIN  Netherlands  Anned  Forces  Integrated  Network 

NAP!  North  American  PCTE  Initiative 

NAPMA  NATO  Aiihotne  Early  Warning  and  Control 
Program  Management  Agency 
NAPO  NATO  Production  Objective 

NAS  Network  Application  Support  (DEC) 

NATO  Nbrfli  Atlantic  Treaty  Organization 

NATO-KD  NATO-International  Code  Designator 
NBS  US  National  Bureau  of  Standards  (now  NIST) 

NBSIR  NBS  Interim  Report 

NC  NATO  Confidential 

NCC  National  Computing  Centre 

NCOS  NATO  Command,  Control  and  Information 
System 

NCD  National  Contribution  Database  (BICES) 

NCGR  Next  Generation  Computer  Resources  (Navy) 

NCIS  NATO  Common  Interoperability  Standards 

NCIS1  Non-Contact  Information  Systems  Interface 

NCN  NATO  Core  Network 

NCS  National  Communications  System  (US 

DoD);  Network  Computing  Services 
NCSC  National  Computer  Security  Center 

NCSL  National  Computer  Systems  Laboratory 

(NIST) 

NCV  Support  for  Naming  Convention  Validation 

(KDS) 

NDDN  Norwegian  Defence  Digital  Network 

NDE  News  Development  Environment  (Sun 

Microsystems) 

NDI  Nondevelopmental  Item 

NDL  Network  Database  Language  (OSD 

NE  The  Netherlands 

NEC  Northern  European  Command 

NEDBAG  NATO  Emitter  Data  Base  Advisory  Group 

NEF  Network  Element  Function 

NET  Telecommunications  European  Norm 

NetBIOS  Network  Basic  Input  Output  System 

NEW  AC  NATO  Electronic  Warfare  Advisory 

Committee  (NATO  Military  Committee) 
NEWWG  NATO  Electronic  Warfare  Working  Group 
NFR90  NATO  Frigate  Replacanent  for  the  19905 
NFS  Network  Hie  System  (Sun  Microsystems) 

NIAG  NATO  Indastrial  Advisory  Group  (CNAD) 

NLAM  Nijssen  Information  Analysis  Method 

NICS  NATO  Integrated  Communications  System 

NIDI  Network  Interface  Definition  Language 

NDDTS  NATO  Initial  Data  Transfer  Service 

(Program) 

Nil  National  Information  Infrastnrcture  (US) 

NIIF  Network  Independent  Interface  (NIAG  SG6) 

NI1S  NATO  Imercoonected  Information  System 

NOT  National  Information  Infrastructure  Testbed 

(US) 

NILE  NATO  Improved  Ltok  Eleven 


NILS  Network  Internal  Layer  Structure 

NIMP  NATO  Interoperability  Management  Plan 

NIPD  NATO  Interoperability  Planning  Document 
NIS  NATO  Identification  System 

NISO  National  Information  Standards  Organization 

NIST  US  National  Institute  of  Standards  and 

Technology 

N1TF  National  Imagery  Transmission  Format 

NTTFS  National  Imagery  Transmission  Format 

Standard  (US  DoD) 

NIU  North  American  (NA)  ISDN  User's  (Forum) 

NL  The  Netherlands 

NLCP  Network  Layer  Control  Protocol  (OSD 

NLI  Network  Layer  Interfax 

NLR  Network  Layer  Relay 

NLS  Native  Language  Support  (X/Open) 

NLSP  Network  Layer  Security  Protocol 

NM  Network  Management 

NMForum  Network  Management  Fonan 
NMOS  NATO  Maritime  Operational  Intelligence 

Support 

NMA  NATO  Military  Authority 

NMP  Networit  Management  Profile 

NMSIG  Network  Management  Special  Interest  Group 
(NACHW) 

NNAG  NATO  Naval  Armaments  Group  (CNAD) 

NNI  Nederlands  Normalisatie-Institnut 

(Netherlands) 

NNTP  Network  News  Transfer  Protocol 

NO  Norway 

NOAA  National  Oceanographic  and  Atmospheric 

Administration  (US) 

NOIS  NATO  Operational  Interoperability  Standards 
NORAD  North  American  Air  Defense 

NOSA  NATO  OSI  Security  Architecture 

NOSIP  NATO  Open  Systems  Imeroonnection  Profile 
NOTS  NATO  Off-the-Shelf 

NP  New  Project  (ISO,  formerly  New  Work  Hem) 
NPDU  Network  Protocol  Data  Unit 

NPI  Network  FYotocol  Interface 

NPICS  NATO  Protocol  Implementation 

Conformance  Statement 

NPIS  NATO  Procedural  Interoperability  Standards 

NPS  Nuclear  Planning  System 

NPT  National  PDES  Testbed  (NIST) 

NR  NATO  RESTRICTED 

NRZ  Non-Return  to  Zero 

NS  NATO  SECRET 

NSA  National  Security  Agency  (United  States) 

NSAI  National  Standards  Authority  of  Ireland 

NSAP  Network  Service  Access  Point  (OSD 

NSF  Network  Hie  System 

NSG  NATO  Standardization  Group  (NAC  in 

NATO) 

NSP  NATO  Standardized  Profile 

NSS  National  Standards  System  (Canada) 

NSSN  National  Standards  System  Network  (US. 

developed  by  NIST) 
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NST  NATO  Staff  Tncaget 

NT  New  Technology 

NTF  National  Transfer  Format  (United  Kingdom) 

NT1S  NATO  Technical  Interoperability  Standards; 

National  Technical  InfbnnatioD  Service 
(United  States) 

NTP  Network  Tune  Protocol 

NTSC  National  Television  System  Committee 

NTT  Nippon  Telegraph  and  Telephone  Corporation 

(Japan) 

NU  NATO  UNCLASSIFIED 

NUICS  North  American  Air  Defense  (NORAD) 
USPAQBCOM  Integrated  Command  and 
Control  System 

NVLAP  National  Voluntary  Laboratory  Accreditation 
Program  (NIST) 

NWI  New  Work  Item  (ISO)  (see  also  NP) 

O/R  Originator/Recipient  (MHS) 

O&M  Operations  and  Maintenance 

OC  Optical  Carrier  (SONET  level) 

OCONUS  Outside  the  Continental  United  States 

ODA  Office  Docvnent  Architecture 

ODAC  Office  Document  Architecture  Consortium 

ODBC  Open  Database  Connectivity  (Microsoft) 

ODCF  Office  Document  Interchange  Format 

(XX-  Office  Document  Language 

CXX*  Open  Distributed  Processing 

<XM  Object  Information  Management 

CXW  OSE  Implementor’s  Workshop 

(M  OSI  Management 

OMA  Object  Management  Architecture  (OMG) 

OMB  Office  of  Management  and  Budget  (US) 

OMG  Object  Management  Group 

OMIPoint  Open  Management  Interoperability  Point 
ONC  Open  Network  Computing  (Sim 

Microsystems) 

OQDBTG  Object-Oriented  Database  Task  Group  (ASC 
X3) 

OpenISE  Open  Information  Systems  Engineering 
(CEO 

OPM  Operational  Messaging  (France) 

OPWP  Operational  Procedures  Working  Party  (MAS 
Army  Board,  NATO) 

ORB  Object  Request  Broker  (OMG) 

ORBAT  Order  of  Battle 

OS  Operating  System 

OS/2  Operating  System  2  (IBM) 

OSA  Open  System  Architecture  (Olivetti) 

OSC  Operational  System  Control  (ZODIAC,  The 

Netherlands) 

OSCRL  Operating  System  Command  and  Response 

OSD  Office  of  the  Secretary  of  Defense  (US  DoD) 

OSE  Open  System  Environment 

OSF  Open  Software  Foundation 

OSI  Open  Systems  Interconnection 


OSI/NMF  Open  Systems  Imerccnnectkn/Network 
Management  Forum 

OSIE  Open  System*  Interconnection  Environment 

OSINET  Open  Systems  Interconnection  Network 

OSINLCP  OSI  Network  Layer  Control  Protocol 
OSIP  Open  Sysim  Interoperability  Profile 

OSITOP  Open  Systems  Interoormectian  for  Technical 
and  Office  Protocol 

OS  UP  OSI  Transaction  Processing 

OSN  Open  Systems  Newsletter 

OSSAI  Open  Systems  Standard  Applications  Interface 

OSTC  Open  Systems  Testing  Consortium 

OSTF  Object  Services  Task  Force  (OMG) 

OTF  Open  Token  Foundation 

PI  Message  Transfer  Protocol  (MHS) 

P2  Interpersonal  Messaging  Protocol  (MHS) 

P3  MTS  Access  Protocol  (MHS) 

P7  Message  Store  Access  Protocol  (MHS) 

PA  Identifier  of  the  Profile  Class  for  AEPs 

PABX  Public  Access  Branch  Exchange 

PAD  Packet  AsaemMy/Dismaembly 

PADP  Panel  an  Air  Defence  PhOoeophy  (NADC) 

PADW  Panel  an  Air  Defence  Weapons  (NADC) 

PAL  Phase  Alternating  Line 

PAPS  Phased  Armaments  Programming  System 

(NATO)  _ 

PAR  IVqjea  Authorisation  Request  (IEEE) 

PAS  Pubtidy  Available  Specification;  data-only 

transmission  protocol  (Ranee) 

PASC  Portable  Application  Standards  Commitiee 

(IEEE)  [(formerly  Technical  Committee  on 
Operating  System  (TCOS)] 

PBX  Private  Branch  Exchange 

PC  Prnnnal  CompiUer 

PCIS  Portable  Common  Interface  Set 

PCM  Pulse  Code  Modulation;  Procedure  Call 

PCNCEP  Political  Consukation  and  NATO  Civil 

PCO  Poim  of  Control  and  Observation 

PCS  PC  Services  (OSFs  DME) 

PCT  Personal  Computer  Teletype  (ZODIAC,  The 

wv_-a - a - 

ncmamm) 

PCTE  Portable  Common  Tool  Envirooment 

PCTS  POSIX  Conformance  Test  Suite 

PCU  Portable  Computer  Unit  (US  Army); 

Programmable  Control  Unit  (packet  radio) 
PDAD  Proposed  Draft  Addendum  (ISO) 

PD  AM  Prupoeed  Draft  Amendment  (ISO) 

ruco  iTOOuci  uenowion  rjtcwngc  jpoonemop 

PTXF  Produa  Definition  Intertbmge  Format 

pDISP  ftopoaed  Draft  International  Standardised 

Profile 

PDL  Page  Description  Language;  Program  Detign 
Language 

PEXi  Public  Data  Network 

PDTR  Proposed  Draft  Technical  Report 
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PDU  Protocol  Data  Unit 

FEB  Pining  and  Execution  Bowl  (QIP) 

PH  Platfonn  External  Interface  (TR 10000-3) 

PHCO  Paged  Field  Entry  Instruction  Control  Object 
PEPCO  Paged  Field  Entry  Pilot  Control  Oigect 
PEM  Privacy  EalMDced  Mail 

PEO-CCS  Program  Executive  Officer,  Command  and 
Control  Systems  (US  Army) 

PER  Packed  Encoding  Rules  (ASN.l) 

PEX  PHIGS  Extension  to  X 

PG  Project  Group 

PHIGS  Pttgratxunet's  Hierarchical  Interact!  ve 

Graphics  System 

ragi  IXS06  icupivn 

PHY  Physical 

PI  Idemifier  of  the  Profile  Class  for  Interface 

Profiles 

PICS  Protocol  Implementation  Conformance 

Statement 

Pfl  ftoiocoi  independent  Interface  (IEEE) 

PK  Programmer’s  Imaging  Kernel 

PKS  Programmer’s  Imaging  Kernel  System 

PIMB  IVie  Interfatir,  Management  Bond 

PIWG  Permanent  Interoperability  Working  Gronp 

(ADSIA) 

PU  Position  Location  Information;  Presentation 

Ubtaiy  Interface  (UI) 

PLP  Packet  Level  Protocol  (XJ25) 

PLPS  Preaentation  Level  Protocol  Syntax 

PM  PTOoessable  Mode  (of  Operations  in  DTAM) 

PMD  Physical  Layer  Medium  Dependent 

PMS  Packet  Multicast  Service 

PN  Project  Number 

PNL  Psdfic  Northwest  Laboratories 

POC  Profile  for  Open  System  Environment 

Components  (EWOS) 

POCAC  APIs  far  Communications  Services  (EWOS 
OSE  ftofiles) 

POCAI  APIs  for  Infarmation  Services  (EWOS  OSE 

Profiles) 

POCAS  APIs  for  System  Services  (EWOS  OSE 

Profiles) 

POCAU  APIs  far  End-User  Services  (EWOS  OSE 

Profiles) 

POOF  Formats  (EWOS  OSE  Profiles) 

POCL  Look  and  Feel  Definitions  (EWOS  OSE 

Profiles) 

POCP  Protocols  (EWOS  OSE  Profiles) 

PODA  Piloting  Open  Document  Architecture 

POE  Profiles  for  Open  System  Environment 

(EWOS) 

POSC  Petrochemical  Open  Software  Corporation 

POSI  Promoting  Conference  for  OSI  (Asia-Oceania 
Regional  Workshop) 

POSIX  Portable  Operating  System  Interface  for 

Comparer  Environments 
PPP  Point-to-point  Protocol 

PPRDB  Partitioned,  Partially  Replicated  Database 


PPSC-IT  Public  Procurement  Subcommittee  in  the 

_  Information  Technology  Sector  (CEC) 

PPTM  Protocol  Profile  Conformance  Testing 

Methodology 

prisNV  Draft  European  Pre-Standard 

PREMO  Presentation  Environment  for  Multi-Media 
Objects 

PRL  Profile  Requirements  List 

PRMD  Private  Management  Domain 

PROST  Program  of  Research  on  Open  System 

Testing 

PRS  Print  Management  Service  (OSPs  DME) 

PSC  Principal  Systems  Command;  Principal 

Subordinate  Cranmand[er];  Primary 
3obofdittic  Coomypd 
PSDN  Packet  Switched  Digital  Network 

PSEIF  Project  Support  Environment  Interfaces 

Standard  (Navy) 

PSESWG  Project  Support  Environment  Standards 
Working  Group  (Navy) 

PSN  Packet  Switched  Network 
PSPDN  Packet  Switched  Public  Date  Network 
PSPvtDN  Picket  Switched  Private  Data  Network 
PSSG  Protocol  Standards  Steering  Group 
PSTN  Public  Switched  Telephone  Network 
PSTP  Protocol  Stsndatds  Technical  Psnel  (see 
DTMP) 

PTI  Public  Tool  Interface 

PTLR  Passive  Transport  Layer  Relay 

PTS  Profile  Test  Specification 

PTT  Postal,  Telegraph,  and  Telephone 

PVC  Permanent  Virtual  CircuM 

PWG  Permanent  Working  Gronp  (ATCCIS) 

PW1  Public  Window  Interface  (specification) 

QkA  Question  and  Answer  (NATO  Identification 
System) 

QCMP  Quadri  lateral  Configuration  Management  Plan 
QIFS  Quadrilateral  Interoperability  Field  System 
(UK) 

QIP  Qntririlateral  Interoperability  lYograratne 
QIPMP  Quadrilateral  Interoperability  Programme 

QMHS  Quadrilateral  Message  HandUng  System 

QoS  Quality  of  Service 

QP  Quadrilateral  Profile 

QRMP  Quick-Reaction  Multicolor  Printer  (US 
Army) 

QSTAG  Quadrilateral  Standardization  Agreement 
QTDMP  Quadrilatenl  Test  and  Demonstration 

QTIDP  Quadrilateral  Technical  Interface  Design  Plan 

QTTR  Quadrilateral  IbdKiical  hitetfaoe  Rwptitemera 

QWERTY  Arrangement  of  keys  on  US  standard 
keyboard 

R  Relay  (profile  dass) 

R4R  Review  and  Releaae 

RA  Remote  Actions  (FTAM) 
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RACWG  Requirement  and  Design  Criteria  Working 
Group  (CAIS) 

RADIUS  Research  and  Development  for  Image 
Understanding  Systems  (US  ARPA) 

RAM  Random  Access  Memory 

RAP  Recognized  Air  Picture  (ACCS);  Radio 

Access  Point 

RARE  Reseaux  A&socies  pour  le  Recherche 
Europeenne  (Association  of  European 
Research  Networks) 

RD  Restricted  Data 

RDA  Remote  Data  Access  (OSD 

RDBMS  Relational  Database  Management  System 
RDCE  RADIUS  Common  Development 
Environment  (US  ARPA) 

RDN  Relative  Distinguished  Name 

RDT  Referenced  Data  Transfer 

Re/KK  Computer  Communication  Shelters 
(Germany) 

RFC  Request  for  Comment 

RFP  Request  for  Proposal 

RFT  Request  for  Technology 

RGB  Red-Green-Biue 

RGPF  Raster/Gridded  Product  Format 

RIPSO  Revised  Internet  Protocol  Security  Option 
RL  Requirements  List 

RLE  Run  Length  Encoding 

RM  Reference  Model;  Relationship  Management 

(systems  management  fraction) 

RMDM  Reference  Model  on  Data  Management 
RNLA  Royal  Netherlands  Army 

RO  Remote  Operations 

RODE  Remote  Open  Document  Editing 

ROMC  Requited  Operational  Messaging 

Characteristic 

ROS  Remote  Operation  Service  (OSD 

ROSE  Remote  Operation  Service  Element  (OSD 

RPC  Remote  Call  Procedure 

RSP  Recognized  Sea  Picture 

RSRE  Royal  Signals  and  Radar  Establishment 

RSTA  Reconnaissance.  Surveillance,  and  Tvget 
Acquisition 

RT  Reliable  Transfer 

RTA  Reliable  Transfer  Agent 

RTDSC  Real-Time  Distributed  Systems 

Communication  (POSIX) 

RTM  Response  Time  Monitoring  (systems 
management  function) 

RTS  Reliable  Transfer  Service  (OSD 

RTSE  Reliable  Transfer  Service  Element  (OSD 

RTTS  Real-Time  Transport  Service 


SACEUR  Supreme  Allied  Commander  Europe 
SACF  Single  Association  Control  Function 
SACLANT  Supreme  Allied  Commander  Adantic 
SAG  SQL  Access  Group 
SAIF  Spatial  Archive  and  Interchange  Format 
SAM  Surface-tD- Air  Missile 
SAME  SQL  Ada  Module  Extensions 
SAMeDL  SQL- Ada  Module  Description  language 
SAMOC  Surfoce-to-Ak  Missile  Operations  Center 
SANISI  Security  Architecture  far  NATO  Information 
Systems  intfrornwrinw 

SANTIS  Single  Architecture  of  NATO  Technical 
Common  Interface  Standards 
SAO  Single  Association  Object 

SAP  Service  Access  Point;  Subnetwork  Access 

Protocol  (Network  Layer) 

SAPI  Service  Access  Point  Identifier  (LAPD) 

SAR  Segmentation  and  Reassembly 

SARWP  Search  and  Rescue  Working  Party  (MAS  Air 
Board.  NATO) 

SASO  Saudi  Arabian  Standards  Organization 
SATCOM  Satellite  Communications 
SC  Sub-Committee  (ISO);  Study  Committee 

SCARS  Status  Control  Alerting  and  Reporting 
System 

SCC  Standards  Council  of  Canads 

SCCOA  Systeme  de  Cootroie  et  de  Commandement 
des  Operations  Aeriemes  (France) 

SCCS  Somce  Code  Control  System  (ATAT) 

SCECP  Senior  Civil  Emergency  Planning  Comminee 
(NACinNATO) 

SCF  Service  Control  Facility  (ATCCIS) 

SCI  Sensitive  InCotmstioQ 

SCPS-TWG  Space  CoBMMDica Protocol 

Standards  Technical  Working  Group  (US) 
SCRA  Single-Channel  Radio  Access 

SCSI  Small  Computer  System  Interface 

SCWUI  Steering  Committee  on  User  Interface  (IEEE) 

SD  Structured  Design 

SD&IC  System  Design  and  Integration  Contract 

(ACEACOS) 

SDCP  Suboetworit  Dependent  Convergence  Protocol 

(OSI  Network  Layer)  _ 

SDE  Secure  Data  Exchange  (IEEE);  System 

Development  Environment 
SDH  Synchronout  Data  Hierarchy 

SDIF  SGML  Document  Interchange  Format 

SDIO  Strategic  Defense  Initiative  Office 

SDL  System  Development  Language  (FDT) 

SDLC  Synchronous  Dam  Link  Control 

SDN  Secure  Data  Network 


RWCC  Regional  Workshop  Coordinating  Committee  SDNS  Secure  Data  Network  System  (US  National 

RWS-CC  Regional  Workshop  Coordinating  Committee  Security  Agency) 


SA 

Security  Association;  Structured  Analysis 

SDS 

Software  Distribution  Service  (OSFs  DME); 
Strategic  Defense  System  (US  DoD) 

SA-P 

Security  Association  (SA)  -  Protocol 

SDTS 

Spstial  Dam  Transfer  Specification 

SAA 

Systems  Application  Architecture  (IBM) 

SDU 

Standalone  Display  Unit 

SABM 

Set  Asynchronous  Balanced  Mode 

SE 

Service  Element 
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SECAN  Military  Committee  Communications 

Security  aid  Evaluation  Agency  (NATO) 

SEE  Software  Engineering  Environment 

SEI  Security  Exchange  Information 

SEP  System  Execution  and  Planning  (ZODIAC, 

The  Netherlands) 

SESE  Security  Exchange  Service  Element 

Seq  <«]»"«* 

SFA  Specified  Subftmctional  Area;  Sensor  Fusion 

Area  (ACCS) 

SFS  Suomen  Standardisoimisliitto  (Finland) 

SG  Subgroup 

SGFS  Special  Group  on  Functional  Standardization 

OSOflECJTCl) 

SGML  Standard  Generalized  Markup  1  anguage 

SHAPE  Supreme  Headquarters  Allied  Powers  Europe 
SHF  Super  High  Frequency 

SHEF  SHAPE  Motmatian  Flow 

SHORAD  Short-Range  Air  Defense 
SIB  Systems  Interoperability  Branch  (CIS 

Division.  IMS.  NATO) 

SICF  Systeme  Inforrnatique  de  Commandement  des 

Forces  Terrestrcs 

SICP  Subnetwork  Independent  Convergence 

Protocol  (OSI  Network  Layer) 

SIF  SSDB  Interchange  Format 
SIG  Special  Interest  Group  (NIST  OSI 
Implementor's  Workshop) 

SIGMA  UNIX  Open  Applications  Group 
SIGCOMM  Special  Interest  Group  on  Data 
Communicarions  (ACM) 

SK3NT  Signals  Intelligence 
SB  System  Interconnection  interface  (MIA) 

SILS  Standard  for  Interoperable  LAN  Socurity 
S1MNET  Simulation  Network  (US  DoD) 

SINCGARS  Single-Channel  Ground/Air  Radio 
System  (US  DoD) 

SIO  Security  Information  Object  (ISO  SC27) 

SIR  Systeme  d*  Information  Regimentaire  (France) 

SIS  Stradarthaeringshnnuniskioen  i  Sverige 

(Sweden) 

SITPRO  Simplified  Trade  Procedures 

SM  System  Manager 

SMA  Systems  Management  Architecture  (ISO) 

SMCS  System  Management  and  Control  System 
(Qnada) 

SMDS  Switched  Multimegabit  Data  Service 

SMF  System  Management  Facility  (ATCCIS); 

System  Management  Function  (ISO) 

SMFA  Systems  Management  Functional  Area 

SMI  Structure  of  Management  Information  (OSI) 
SMP  System  Management  Protocol 

SMPTE  Society  of  Motion  Picture  and  Television 
Engineers 

SMS  SwetSsh  Mechanical  Standwdization; 

Subsystem  Management  Service  (OSFs 
DME) 

SMSL  Standard  Multimedia  Scripting  Language 

SMT  Station  Management  (FDDI) 


SMTP  Simple  Mail  Transfer  Protocol  (US  DoD) 

SN  Subnetwork 

SNA  System  Network  Architecture  (IBM) 

SNARE  Subnetwork  Address  Resolution  Entity 
SNC  Special  Network  Concentrator  (Germany) 

SNDCF  Subnetwork-Dependent  Convergence 
Function 

SNDCP  Subnetwork  Dependent  Convergence  Protocol 
(OSI  Network  Layer) 

SNE  Special  Network  Exchange  (Germany) 

SNES  Special  Network  Exchange-Small  (Germany) 

SNI  Simple  Network  Interface  (IEEE) 

SNICP  Subnetwork  Independent  Convergence 
Protocol  (OSI  Network  Layer) 

SNMP  Simple  Network  Management  Protocol 
(Internet) 

SNO  Special  Network  Operations  and  Maintenance 

(Q&M)  (center)  (Germany) 

SNP  A  Subnetwork  Point  of  Attachment 

SNV  Swiss  Association  for  Standardization 

SOGITS  Senior  Official  Group  for  Information 
Technology  Standardization  (CEC) 

SOGT  Senior  Official  Group  on 

Telecommunications  (CEO 
SOM  System  Object  Model 

SOSTA  Stand-Off  Surveillance,  Target,  and 

Acquisition 

SOTAS  StandOff  Target  Acquisition  System  (US) 

SP  Security  Protocol  (SDNS);  Spain 

SPACECOM  Space  Command 
SPAG  Standards  Promotion  and  Applications  Group 
SPARC  Standards  and  Planting  Requirements 

Committee 

SPDL  Standard  Page  Description  language 

SPI  Standard  Programmatic  Interface  (SC21) 

SPX  Sequence  Packet  Exchange  (Internet) 

SQL/MM  SQL  for  Multimedia  and  Application 

Packages 

SRT  Source  Routing  Transparent  (LAN  Bridging) 
SSDB  Standard  Simulation  Data  Base 

SSI  System  Software  Interlace 

SSP  Subnetwork  Specific  Protocol  (Network 

Layer) 

SSS  Side-Scan  Sonar  (Distribution);  System 

Segment  Specification 

STACCON  Italian  Army  tactical  CCIS  (QIP) 

ST  ACCS  Standard  Theater  Anny  Command  and 
Control  System  (see  AGCCS) 

STAMINA  Standard  Automated  Message  Processing 
Interface  for  NATO’s  ACOSs 
STANAG  NATO  Standardization  Agreement 
STC  SHAPE  Technical  Centre 

STD  Standard 

STDL  Structured  Transaction  Definition  Language 

(MIA) 

STDN  Strategic-Tactical  Dam  Network  (US  DoD 
interoperability  demonstration  activity) 

STE  Signalling  Terminal 
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STEI  Service  Technique  derEkctroniqueetde  TCCS 

I’lnfonnadque  (France)  TCDN 

STEP  Standard  for  the  Exchange  of  Product  Model 

Data  TCG 

STL  Standard  Text  Language  TCIS 

STM  Synchronous  Transfer  Mode  (SONET  level) 

STN  Switched  Telephone  Network  TCOS 

STP  Shielded  Twisted  Pair  (cable) 

STR  Strategic  (standard)  TCP 

STRADIS  Structured  Analysis,  Design  and  TCP/IP 

Implementation  of  Information  Systems 
STRIDA  Systeme  de  Traitement  et  de  Representation  TCS 

des  Informations  de  Defense  Aerienne  (FR)  TCSEC 

STS  Synchronous  Transport  Signal  (SONET  TCSS 

level) 

SUCOC  Succession  of  Command  TCT 

SUMM  Semantic  Unification  Meta  Model  (IRDS)  TCU 

SVC  Stored  Video  Camera 


SVR4  System  V  Release  4  (AT&T  and  BSD  UNIX)  TDC 
SVID  System  V  Interface  Definition  (AT&T  UNIX)  TDI 


SWG  Special  Working  Group  (ISO  JTC1)  TDM 

SWG-CA  Special  Working  Group  on  Conformity  TDN 

Assessment  (ITC1)  TDP 

SWG-EDI  Special  Working  Group  on  Electronic  Data  TEI 
Interchange  TEK 

SWG-MF  Special  Working  Group  on  Modelling  TELNET 

Facilities  (JTC1)  Telcos 

Synch  Synchronous;  Synchronized  TEM 

SYSCOM  System  Control  and  Management  JEN 

(ZODIAC,  The  Netherlands)  jp 

TFA 

T  transport  profile  class  providing  COTS  xGA 

TAC  Tactical;  Tactical  Communications  Protocol  tcrm 

TACFIRE  Tactical  Fire  Direction  System 
TACS  Tactical  Air  Control  System  (US  Air  Force)  THN 

TACSATCOM  Tactical  Satellite  Communications  HDP 

TADIL  Tactical  Digital  Information  Link  TIFF 

TADIXS  Tactical  Information  Exchange  System  (US  TLI 

Navy) 

TADKOM  Norwegian  tactical  area  communications  TLSP 
system  JLV 

TAOM  Tactical  Air  Operations  Module  (US  DoD)  TM 

TARE  Telegraph  Automated  Routing  Equipment 

TASDAC  Tactical  Secure  Data  Communications  (US  TMD 


TAWP 

TBD 
TBITS 

TBM 
TC 

TCA 
TCAC 
TCC 
TCCA 

TCCCS  Tactical  Command  Control  Communications  ™ 
System  (Canada) 


Air  Force) 

Tactical  Air  Working  Party  (MAS  Air  Board, 
NATO) 

To  Be  Determined 

Treasury  Board  Information  Technology 
Standard  (Canada) 

Tactical  Battle  Management  (US  DoD) 
Transport  Connections;  Technical  Committee 
(BO) 

Telecommunications  Association 
Technical  Control  and  Analysis  Center 
Time-Critical  Conunonications 
Time-Critical  Communications  Architecture 


TMHS 

TMN 

TMP 

IMS 

TN 

TNI 

TON 

TOP 

TOR 

TP 

TP4 

TPDU 


Tune-Critical  Communkations  System 
Tactical  Communications  Distribution  Node 
(US  Marine  Corps) 

Technical  Coordination  Group  (CNSI) 
Technical  Common  Interface  Standards 
(TSGCESG9) 

Technical  Committee  on  Operating  Systems 
(IEEE) 

Transmission  Control  Protocol  (US  DoD) 
Transmission  Control  Protocol/Intemet 
Protocol 

Trusted  Communications  Sublayer  (SANISI) 
Trusted  Computer  System  Evaluation  Criteria 
Telecommunications  Systems  Standards  (US 
DoD) 

Tactical  Computer  Terminal 
Transportable  Computer  Unit  (US  Army); 
Terminal  Control  Unit  (packet  radio) 

Time  Dispersal  Coding 
Trusted  Database  Interpretation 
Time  Division  Multiplexing 
Trunk  Distribution  Network  (Canada) 
Technology  Demonstrator  Programme  (UK) 
Terminal  Endpoint  Identifier  (LAPD) 

Traffic  Encryption  Key 
Telecommunications  Network 
Telecommunications  Service  Provider 
Terrain  Evaluation  Module  (US  Army) 
Tactical  Extension  Node  (Canada) 

Transfer  Facility  ( ATCOS) 

Transparent  File  Access  (POSIX) 

Targa  Image  Format 

Technical  Group  on  Reference  Models 

(ECMA) 

Territorial  Host  Nation 

Technical  Interface  Design  Plan 

Tag  Image  File  Format 

Transport  Library  Interfnce;  Transport  Layer 

Interface 

Transport  Layer  Security  Protocol 
Tag-Length-Value 
Technical  Management;  Technical 
Memorandum;  Terminal  Mratagcmeat 
Terminal  Management  Domain  (TM) 

Tactical  Message  Handling  System  (Canada) 
Telecommunication  Management  Netwmk 
Test  Management  Protocol  (TP) 

Tactical  Message  Switch  (Norway) 

Technical  Note  (STC) 

Trusted  Network  Interpretation 
Trunk  Node  Network 
Technical  and  Office  Protocol 
Terms  of  Reference 

Transaction  Processing  (OS  I);  Transport 
Protocol  (OSD 
Transmission  Protocol  4 
Transport  Protocol  Data  Unit  (OSI) 

Transport  Layer  Protocol  Interface 
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TPN 

Tactical  Packet  Network  (US  Army) 

urr 

Union  Internationale  des  Telecommunications 

TPSUI 

Ttansactioo  Processing  Service  User 

(CCITT) 

Invocatkn 

UK 

United  Kingdom 

TR 

Technical  Report  (ISO) 

ULA 

Upper  Layer  Architecture  (OS  I) 

TRAS 

Tactical  Rattio  Access  System  (Norway) 

ULTDS 

Unit  Level  Tactical  Data  Switch 

TRI-MNC 

!  Tri-Major  NATO  Commanders'  Command 
and  Control  Plan 

UN 

Unsynch 

United  Nations 

Unsyncfaronized 

TRI-TAC 

Joint  Tactical  Communications  Program  (US  UOD 

Universe  of  Discourse 

DoD) 

UQF 

Unit  of  Functionality  (TR  10000-3) 

TRM 

Technical  Reference  Model  (US  DoD) 

URSI 

International  Union  of  Radio  Science 

TRP 

Technical  Reinvestment  Project 

USACOM 

[  US  Atlantic  Command 

TRR 

Tactical  Multi-Role  Radio  (Norway) 

USAPGWS  United  Stales  Air  Force  Global  Weather 

TS 

Transport  Service  (OS I);  Telecommunication 

Service 

Standardization  Sector  (TTU) 

USAREUR  US  Army  in  Europe 

TSA 

Tune  Synchronization  Agent 

USGS 

US  Geological  Survey 

TSAG 

Telecommunication 

USL 

UNIX  Systems  Laboratories  (formerly 

TSAP 

Transport  Service  Access  Point 

AT&T,  now  a  wholly  owned  subsidiary  of 

TSDN 

Transfer  Syntax  Description  Notation  (ASC 

Novell.  Inc.) 

X3T2) 

USPACOM  US  Pacific  Command 

TSG 

Technical  Study  Group  (ISO/IEC  JTC1) 

US-SIOP-ESI  United  Stales  -  Single  Integrated 

TSGCE 

Tri-Service  Group  on  Communications  and 
Electronics  (NATO)  (formerly  TSGCEE) 

Operation  Plan  •  Extremely  Sensitive 
Information 

TSS 

Tune  Synchronization  Service 

USSPACECOM  US  Space  Command 

TSSTP 

Test  Suite  Structures  and  Test  Purposes 

UTACCS 

USAREUR  Tactical  Command  and  Control 

TTA 

T elecommunications  Technology  Association 

System  (now  ST ACCS;  see  also  AGCCS) 

(Korea) 

UTC 

Coordinated  Universal  Time 

TTC 

Telecommunications  Technology  Committee 

UTE 

Union  Technique  de  I'Electricrie  (France) 

(Japan) 

UTP 

Unshielded  Twisted  Pair  (cable) 

TTCN 

Tree  and  Tabular  Combined  Notation  (ISO) 

TTGC 

Tactical  Terminal  System  (Prance) 

VC 

Virtual  Circuit 

TIL 

Tune  to  Live  (XTP) 

VC c 

Verification  Coordinating  Committee  (NAC 

TTY 

Teletype 

in  NATO) 

TUA 

Time  User  Agent 

va 

Virtual  Channel  Identifier  (AIM) 

TUBA 

TCP/User  Datagram  Protocol  (UDP)  with 

Big  Addresses 

VEti 

VDM-SL 

Virtual  Device  Interface 

Vienna  Development  Method-Specification 

TWO 

Technical  Workng  Group 

Language 

TXI 

X/Open  Transport  Interface 

VDT 

VDU 

Visual  Display  Terminal 

Visual  Display  Unit 

U 

transport  profile  class  providing  CLTS 

VEX 

Video  Extension  to  X 

UA 

User  Agent  (MHS) 

VFUIF 

Voice/Fax  User  Interface  Fonan 

UAV 

Unmanned  Aerial  Vehicle 

VIM 

Vendor  Independent  Messaging  (Lotus 

UCCS 

USAREUR  Command  Center  System  (US 
Army) 

VMD 

Development  Carp.) 

Virtual  Manufacturing  Device 

UCS 

Universal  Coded  Character  Set  (ISO) 

VMEbus 

Versa  Module  Europe  Bus 

UDO 

User  Descriptor  Object  (TM) 

VMF 

Variable  Message  Format 

UDP 

User  Datagram  Protocol 

VMUIF 

Voice  Messaging  User  Interface  Forum 

UDT 

Unstructured  Data  Transfer 

VPF 

Vector  Product  Format  (DMA) 

UDWP 

Underwater  Diving  Working  Party  (MAS  • 

VPI 

Virtual  Path  Identifier  (ATM) 

Navy  Board.  NATO) 

VPS 

Vector  Product  Standard 

UER 

Union  Europeenne  de  RadiodifTuskn 

VSAT 

Very  Small  Aperture  Terminal 

(European  Union  on  Radio  Broadcasting) 

VSLAN 

Verdix  Secure  LAN 

UHF 

Ultra  High  Frequency 

VSR 

Validation  Summary  Reports  (SQL) 

UI 

UNIX  International 

VT 

Virtual  Terminal  (OSI  Layer  7) 

IWL 

User  Interface  Definition  Language 

VTC 

Video  Teleconferencing 

UJL 

User  Interlace  Language 

VTE 

Virtual  Terminal  Environment 

UIMS 

User  Interface  Management  System 

VTP 

Virtual  Terminal  Protocol 

UISRM 

User  Interface  System  Reference  Model 

VXI 

Extensions  for  Instrumentation 
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WAM  WWMCCS  Automated  Data  Processing 
( ADP)  Modernization 
WAN  Wide  Area  Network 

WAS  Wide  Area  Subsystem 

WAVELL  UK  Army  COS 
WD  Working  Draft 

WDAD  Working  Draft  Addendum  (ISO) 

WDAM  Working  Draft  Amendment  (ISO) 

WDB  World  Data  Bank 

WDISP  Working  Draft  International  Standardized 
Profile 

WDS  WRRE  Demonstrator  System 

WES  WAVELL  Enhancement  System 

WG  Working  Group 

WHIDDS  War  Headquarters  Information  Dissemination 
and  Display  System 
WHQs  WarHeadquanen 

WIMP  Wtndows-Icons-Memis-Potnler  (user  interface) 

WIN  WWMCCS  Intercomputer  Network 

WIS  WWMCCS  Information  System 

WOSA  Windows  Open  Services  AichUectoe 

(Microsoft) 

WP  Working  Paper  (ATCOS);  Working  Piny 

WRRE  WAVELL  Risk  Reduction  Exercise 

WS  Workstation 

WSF  Workstation  Function 

WTSC  World  Telecommunication  Sr«n danftration 

Conference  (formerly  COTT  Plenary 
Assembly) 

WWMCCS  Worldwide  Military  Command  and  Caotroi 
System 


XVS  X/Open  System  V  Specification 

XVT  Extensible  Virtual  Toolkit 

ZODIAC  Zone  Digital  Automatic  Cryptographic  (The 


XU  X'Windows,  Version  11 

XALS  Extended  ALS  (OSD 

XAP  X/Open  ACSE/Presentation  API 

XAPIA  X.400  Application  Programming 


XDS 

Association 

X/Open  Directory  Service 

XDSX 

X/Open  Directory  Services  API 

XFTAM 

X/Open  FT  AM  API 

XIA 

X  Industry  Association 

XID 

Exchange  Identification 

XIE 

X-Image  Extension 

XLib 

X  library 

XOM 

OSI  Object  Management  API 

X/Open 

UNIX  Open  Application  Group  (consortium) 

XPG 

X/Open  Portability  Guide 

XPG3 

Third  Edition  of  the  X/Open  Stability 
Gride 

XPG4 

Fourth  Edition  of  the  X/Open  Portability 

XRUA 

X- Window-Based  Remote  User  Agent 

XSI 

X/Open  System  Interfaces 
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X  Toolkit  Intrinsics 
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Xprca  Transfer  Protocol 
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X  Teleconferencing  and  Viewing 
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